K42 OS

[Michal Ostrowski]

On Fri, 2003-11-21 at 19:13, Bill Huey wrote:
> On Thu, Nov 20, 2003 at 07:50:57PM -0500, Michal Ostrowski wrote:
> > On Thu, 2003-11-20 at 19:31, Matthew Dillon wrote:
> > >     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.
> ... 
> > Underneath all of this, I think there are interesting issues arising
> > from interactions between thread management and IPC.  
> 
> Like what ? priority messaging issues ? just curious.
> 

In sending async messages, how does one handle situations where the
receive buffer of the target is full?

When doing a synchronous message, what happens is the receiver at the
moment is not willing to receive? (we want to efficiently be able to
retry later by some means)

An IPC is handled on a thread that is running in the "server" process.
How is that thread scheduled (what priority)?  How do we account for the
time? (In K42 we attempt to charge time a process spends servicing IPC
requests to the callers of those services.)  
  
(This is not my particular area of expertise, I'm just referring to some
issues off the top of my head.  I can certainly refer you to someone who
is our real expert in this area with specific questions.)

> > 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.
> 
> Is this a Linux emulator ? Something that might be kind of interesting
> is the possiblity of borrowing code from each project for implementing
> a Linux emulator. How complete are your Posix threading semantics ? just
> curious again about corner cases. :) Those things have been a classic
> killer in Solaris and other M:N threading systems.
> 

This is explained in our Freenix paper.

The basic idea is that a K42 process consists of "exec.so" which is the
first thing loaded into a processes address space. exec.so contains code
that implements the Linux system call API.  exec.so then loads the Linux
application (and the dynamic linker/loader if appropriate)  and lets
them run.   We reflect system-call traps back to exec.so (or a
k42-specific glibc will make calls into the system call handlers
directly).

Our current approach to pthreads is to rely on Linux libraries; we
recognize the appropriate clone() calls and create new threads in
response to those.  The rest of exec.so must then be careful to present
linux-threads compatible viewsof the world (e.g. threads appear to be
processes).   We don't have the corner cases, our implementation is good
enough for now, and not complete (we implement things "on-demand").

We need to revisit this space in the near future as we look at the new
Linux pthreads model.

It's important to understand in this space what one wants to support. 
Supporting pthreads is one thing, supporting linuxthreads (i.e. the
linux-specific assumptions about thread properties and behavior) is
quite another.  I believe we should support pthreads and not
linuxthreads.

-- 
Michal Ostrowski <mostrows at xxxxxxxxxxxxxx>
Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00016.pgp
Type: application/octet-stream
Size: 189 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20031122/20fc7a4f/attachment-0020.obj>