Re: K42 OS

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:We have a messaging facility we generically call "PPC" -- Protected
:Procedure Call.  The idea here is that "messages" between processes
:(which may include the kernel) are implemented using procedure call
:semantics and interfaces.   In the synchronous version of a PPC call
:arguments are marshalled into a transfer page, and control is
:transferred to the targeted process that implements the call.  While the
:call is being performed the caller application is still runnable (other
:threads may run), the calling thread is in a state that marks it as
:waiting for a reply.  When the call is complete and the results
:transferred back to the caller the calling thread is resumed. =20
:
:In the asynchronous version of a PPC, the arguments to the PPC call are
:collected in a special buffer of the receiving process that accumulates
:all incoming asynchronous calls, and a "soft interrupt" bit is raised.=20
:When a soft interrupt is raised, the kernel makes the process runnable
:if it was not already and enters the process at a special entry point.=20
:The process then proceeds ton instantiate threads to service the async
:requests.
:
:In the interest of brevity I'm doing a real hack of an explanation
:here.  There is something underlying all of this that I really need to
:stress;  the K42 implementation of all this stuff makes this all work by
:having tight integration between the threading, scheduling and messaging
:facilities.   For example, our core threading facilities must be able to
:recognize that threads are not runnable since they are waiting for a
:message response.  Also, when we make a synchronous call, the time spent
:servicing that call should count towards the run-time of the caller
:process, even though another process is actually executing. (I could go
:on and on, there are many corner cases to worry about.)
:
:
:> folks have another really interesting thing with the option of doing both=
: soft
:> and hard preemption for the userspace threading system, where the "soft" =
:method
:> is a request to the thread-kern to save its state in userspace if possibl=
:e within
:> a certain time frame, while the "hard" version has the kernel do a full c=
:ontext
:> save explicitly. The previous method is presumed to be faster.
:>=20
:
:Correct.
:
:
:> Last paper I read, you folks where having a problem with process migratio=
:n with
:> your scheduler activations stuff. Not sure what can be said here. Did you=
: guys fix
:> it or find the problem ? ;)
:>=20
:
:That is being worked on.  I am assuming that you are referring to the
:issue of how to determine which processor a process should be bound to.
:
:> Just trying to fuel a conversation here. :)
:>=20
:> I think you'll find Matt and a number of his cohorts to be an open minded=
: people
:> and willing to learn from other folks, which is why me and other people h=
:ave faith
:> in his ideals since he's focus on the relevant SMP scalability issues.
:
:That's reassuring to hear.  I certainly hope we can foster a lively
:discussion.
:
:
:--=20
:Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>