Re: [RFC PATCH 00/11] an introduction of library operating system for Linux (LibOS)

[Hajime Tazaki <tazaki@wide.ad.jp>]

Hi Richard,

At Thu, 26 Mar 2015 19:55:06 +0100,
Richard Weinberger wrote:

> >> 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.

the scheduler is the part of which a library user (NUSE or
DCE) should implement.

> 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.

one way to avoid the duplication is: to put our
libos-specific implementation to the kernel core
subsystem. Maybe this will introduce a bunch of #ifdefs
(ifdef CONFIG_LIB) into cores, which I don't know it's okay
or not.

for example, add_timer() is implemented in arch/lib/timer.c
while in kernel/time/timer.c in kernel core.

# [04/11] to [08/11] of my RFC patches are these parts.

We've been implemented these stubs (we call 'kernel glue
code') into arch/lib because 1) we were in out-of-tree and
2) this won't disturb kernel core.


OTOH, [03/11] (and [09/11] and [10/11]) is an original part
of libos, which probably have no conflict (in terms of the
concept) to the others. I'm still thinking arch/lib is an
appropriate place.


> >> 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.

indeed, 'something between' would be an appropriate word.

thank you for your comment.

-- Hajime