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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
