Re: L4::BSD, Subclass your OS

On May 11, 2006, at 12:48 PM, R. Tyler Ballance wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On May 11, 2006, at 1:05 PM, ernesto bascon wrote:
>
>> As I could understand, you want to do something similar to L4Linux  
>> but using BSD kernel instead of the Linux kernel and programming  
>> the drivers are as plugins on top of the L4 microkernel, doesn't you?
>>
>> A lot of things are not enough clear to me yet, by example, how  
>> the shared libraries are handled? they are loaded by every module?  
>> is there some "library manager"? or should be a library manager  
>> implemented as module? if it is so, the routine calls are done via  
>> IPC too?
>>
>
> I definitely understand your thoughts, but I don't think you're  
> completely clear on how shared libraries work in L4Linux (http:// 
> os.inf.tu-dresden.de/L4/LinuxOnL4/overview.shtml). I'm not 100%  
> certain, but as far as I can tell, since Linux runs as essentially  
> "an application" (i.e. user-land address space) on top of the L4  
> kernel, the Linux kernel is responsible for managing all that  
> shared library nonsense, in effect L4::Pistachio runs L4Linux in  
> the address space between 20 and 65 (very generalized from my  
> understanding of the process) and then L4Linux manages the address  
> space between 20 and 65 as if it were running on any other machine,  
> so if it decides to manage shared libs at 60-65, then that's fine,  
> Linux applications would be directed to the address space between  
> 60 and 65 to link up to those shared libraries.

The linux kernel is but a small piece of the horribly complicated  
shared library puzzle.  Really a lot of that is done in userland  
space.  The kernel has to assist with loading binaries of all sorts  
of course but the runtime linkers have to resolve all the dependencies.

> Feel free to chime in (anybody) if I'm mistaken here.
>
> In implementation I don't think an L4::BSD system would perform  
> much differently, with the exception of working in some of Darbat's  
> IOKit stuff (that unified driver idea really fascinates me ;))
>

You don't need DarBat to do unified drivers I don't think... also  
check the license for IOKit and make sure you can even use it the way  
you're looking to.

> Basically, I think we have two fantastic references to look at when  
> deciding on how such an OS should be built, L4Linux, and L4/Darwin.  
> (L4Linux moreso, since L4/Darwin seems to been more of "merely" (no  
> small task) taking Mach in, and switching it for L4, and emulating  
> anything else that Xnu did underneath Darwin)
>
> Feel free to stop by #l4bsd, early a KDE and opendarwin developer  
> dropped by as well as the project manager from NICTA's Darbat  
> project, both offering up some very useful opinions and ideas.
>

Good luck on this... :)  I'll be lurking to see what happens.

> Cheers,
>
> - -R. Tyler Ballance
>
> p.s. sorry about the triple-PGP signing of the initial post,  
> GPGMail went nuts on me.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
>
> iD8DBQFEY5UQqO6nEJfroRsRApRdAJ0aPT+IlRx9O1rTDUYcAlpl1IMd1wCdGzE6
> Jq6KZKHpYEptXQsVMvem8lI=
> =wvCU
> -----END PGP SIGNATURE-----
>