[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5514560A.7040707@nod.at>
Date: Thu, 26 Mar 2015 19:55:06 +0100
From: Richard Weinberger <richard@....at>
To: Hajime Tazaki <tazaki@...e.ad.jp>
CC: linux-arch@...r.kernel.org, arnd@...db.de, corbet@....net,
cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
netdev@...r.kernel.org, linux-mm@...ck.org, jdike@...toit.com,
rusty@...tcorp.com.au, mathieu.lacage@...il.com
Subject: Re: [RFC PATCH 00/11] an introduction of library operating system
for Linux (LibOS)
Hi!
Am 26.03.2015 um 17:24 schrieb Hajime Tazaki:
> thank you for your deep review on the source code !
>
>> feeling that "lib" is the wrong name.
>> It has not much do to with an architecture.
>
> could you care to elaborate your feeling more explicitly ?
>
> what is an architecture here and what is _not_ an
> architecture ?
> is UML an architecture in your sense (probably yes, but why)?
UML is an architecture as it binds the whole kernel to a computer
interface. Linux userspace in that case.
> and what is arch/lib missing for an architecture ?
Your arch/lib does not bind the Linux kernel to an interface.
It takes some part of Linux and duplicates kernel core subsystems
to make that part work on its own.
For example arch/lib contains a stub implementation of core VFS
functions like register_filesystem().
Also it does not seem to use the kernel scheduler, you have your own.
This also infers that arch/lib will be broken most of the time as
every time the networking stack references a new symbol it
has to be duplicated into arch/lib.
But this does not mean that your idea is bad, all I want to say that
I'm not sure whether arch/lib is the right approach.
Maybe Arnd has a better idea.
>> Apart from that, I really like your idea!
>
> great to hear that ;)
>
>> 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.
>
> again, the above same questions.
>
> it (arch/lib) is a hardware-independent architecture which
> provides necessary features to the remainder of kernel code,
> isn't it ?
The stuff in arch/ is the code to glue the kernel to
a specific piece of hardware.
Your code does something between. You duplicate kernel core features
to make a specific piece of code work in userland.
> answers to those questions are really helpful for a feedback
> on this RFC patches.
>
>> BTW: It does not build here:
>> ---cut---
>> LIB liblinux-4.0.0-rc5.so
>
> fixed, thanks: though the issue was in the external code
> base (i.e., linux-libos-tools). there was a parallel build
> (make -jX) problem.
>
> # you may need to git pull at arch/lib/tools to reflect the updates.
Will retry later.
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists