From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752474AbbCYWug (ORCPT ); Wed, 25 Mar 2015 18:50:36 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:65276 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752404AbbCYWuc (ORCPT ); Wed, 25 Mar 2015 18:50:32 -0400 Message-ID: <55133BAF.30301@nod.at> Date: Wed, 25 Mar 2015 23:50:23 +0100 From: Richard Weinberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hajime Tazaki CC: linux-arch@vger.kernel.org, arnd@arndb.de, corbet@lwn.net, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, jdike@addtoit.com, rusty@rustcorp.com.au, mathieu.lacage@gmail.com Subject: Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS) References: <1427202642-1716-1-git-send-email-tazaki@sfc.wide.ad.jp> <551164ED.5000907@nod.at> <55117565.6080002@nod.at> <55118277.5070909@nod.at> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! Am 25.03.2015 um 15:48 schrieb Hajime Tazaki: > > At Tue, 24 Mar 2015 16:27:51 +0100, > Richard Weinberger wrote: >> >> I'd say you should try hard to re-use/integrate your work in arch/um. >> With um we already have an architecture which targets userspace, >> having two needs a very good justification. > > in addition to the case of my previous email, libos is not > limited to run on user-mode: it is just a library which can > be used with various programs. thus it has a potential (not > implemented yet) to run on a hypervisor like OSv or MirageOS > does for application containment, or run on a bare-metal > machine as rumpkernel does. We already have a clear > interface for the underlying layer to be able to add such > backend. > > again, it's not only for user-mode. > > mixing all the stuff in a single architecture may not only > mislead to users, but also introduce conceptual-disagreements > during code sharing of essential parts. > > I don't see any benefits to have a name 'um' with this idea. > > # I'm not saying sharing a part of code is bad idea at all, btw. After digging into the source I know what you mean and I have the feeling that "lib" is the wrong name. It has not much do to with an architecture. Apart from that, I really like your idea! You don't implement an architecture, you take some part of Linux (the networking stack) and create stubs around it to make it work. That means that we'd also have to duplicate kernel functions into arch/lib to keep it running. BTW: It does not build here: ---cut--- LIB liblinux-4.0.0-rc5.so Cloning into 'arch/lib/tools'... remote: Counting objects: 93, done. remote: Compressing objects: 100% (19/19), done. remote: Total 93 (delta 9), reused 0 (delta 0), pack-reused 74 Receiving objects: 100% (93/93), 59.77 KiB | 0 bytes/s, done. Resolving deltas: 100% (43/43), done. Checking connectivity... done CC nuse-fiber.o CC nuse-vif.o CC nuse-hostcalls.o CC nuse-config.o CC nuse-vif-rawsock.o CC nuse-vif-tap.o CC nuse-glue.o CC nuse-vif-pipe.o CC nuse.o make[2]: *** No rule to make target `rump/lib/librumpuser/rumpuser_sp.c', needed by `rump/lib/librumpuser/rumpuser_sp.o'. Stop. make[2]: *** Waiting for unfinished jobs.... CC sim.o GEN git-sparse make[2]: *** No rule to make target `rump/lib/librumpclient/rumpclient.c', needed by `rump/lib/librumpclient/rumpclient.o'. Stop. make[1]: *** [librumpclient.so] Error 2 make[1]: *** Waiting for unfinished jobs.... nuse.c: In function 'nuse_dev_rx': nuse.c:279:5: warning: unused variable 'hdr' [-Wunused-variable] } *hdr = (struct ethhdr *)buf; ^ make[1]: *** [librumpserver.so] Error 2 make: *** [arch/lib/tools] Error 2 ---cut--- Thanks, //richard