DragonFly kernel List (threaded) for 2008-06
DragonFly BSD
DragonFly kernel List (threaded) for 2008-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: User API still a goal?

To: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
From: Michael Neumann <mneumann@xxxxxxxx>
Date: Wed, 04 Jun 2008 01:13:39 +0200

Matthew Dillon wrote:
:No, I was thinking about the messaged system calls and emulation of e.g.
:Linux of FreeBSD system calls (in user-mode). As non-DragonFly native
:binaries wouldn't know about messaged system calls, it was intended to
:provide some kernel-protected (but user-mode) emulation layer, that
:translates those syscalls to DragonFly native messages.
:So an int 80h would call a function inside the user-mode process, which
:then translates the syscall to a proper message call. Of course that
:wouldn't be as fast as a direct system call.
:   Michael

    Ah yes, I remember that.  I still think that is the best way to go but
    I simply ran out of time trying to implement it.  It was holding up too
    much other work so I dropped it.

You wrote in the goals section: "pass structural information through capability and element lists instead of as raw structures".

How can I image the use of capability and element lists? What is it
exactly? Is it some kind of typed union data structure, like for

  object arr = obj_array_new(1000);
  obj_array_set(arr, 0, obj_string_new("abc"));
  obj_array_set(arr, 1, obj_integer_new(123232));
  object ref = obj_ref(arr); // reference counting
  obj_unref(ref);  // array gets freed


This is similar to problib of NetBSD [1], or similar to scripting
languages like Python or Ruby (which just add nice syntax and garbage

Btw, something like the above could be quite useful in communicating
arbitrary structures between userland and kernelland (or also for
specifying device hints or quirks at runtime).

You further write "One no longer needs multiple kernel contexts or
stacks to deal with multiple userland threads, one needs only one kernel
context and stack per user process."
Does this mean that the single kernel context would be just a lwkt
thread that "listens" for messages from it's userland threads and then
forwards them to the right subsystem? In this case, asynchronous sends
have to be used, otherwise all userland lwkt threads would be blocked.
That is, it would only work as you describe it, if all subsystems have
their own handler thread.

    Right now my personal push is HAMMER, for the 2.0 release, and then
    HAMMER replication (some time after 2.0), and then moving on to the
    main clustering goal.

Yeh, and that's definitively great!



[1]: http://netbsd.gw.com/cgi-bin/man-cgi?proplib++NetBSD-current

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]