User API still a goal?

[Michael Neumann]

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.
:
:Regards,
:
:   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
example:
  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(arr);
  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
collection).
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!

Regards,

  Michael

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