Re: K42 OS

[Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>]

On Thu, 2003-11-20 at 19:31, Matthew Dillon wrote:
>     There seem to be a lot of similarities between K42 and DragonFly.  I have
>     a very light weight but powerful messaging subsystem in the kernel
>     (kern/lwkt_msgport.c) which I am right now porting to userland, and I
>     intend to use it for IPC purposes as well.  
> 
>     I am not trying to create a procedural abstraction, but I do intend to use
>     messaging to initiate syscalls so in a sense that is a procedural 
>     abstraction of a kind since it causes things like read() to be moved into
>     libc and actually build, dispatch, and wait for the syscall message
>     rather then make a directly 'read' system call.
> 


The procedural abstraction I think makes more sense for us since we are
working in C++, are object-oriented and thus have large numbers of
interfaces.  The K42 procedural abstraction hides the mechanism of
performing these messaging functions (in fact the code that does the
guts of the messaging is mostly code generated by our tools to translate
between the procedural interfaces and the underlying messaging
facilities).

Underneath all of this, I think there are interesting issues arising
from interactions between thread management and IPC.  

With regard to the second issue you've touched upon, we implement UNIX
API's as you've described.  Our approach to this has been to move as
much functionality into the application as possible.  Thus things such
as file-cursor management can be handled within the application under
certain circumstances, and poll()/select() are implemented completely
within the application.   Such an approach allows us to potentially
supply specialized implementations of services on a resource by resource
basis.

-- 
Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part