DragonFly kernel List (threaded) for 2008-06
Re: User API still a goal?
: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
: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).
This went through a minor evolution and I think I still have some
lib API code to help support it somewhere.... ah yes, I do. It
is called /usr/src/lib/libcaps.
It is very old and there is some cruft in there, but the basic
principle hasn't changed.
The idea is to characterize the system structures passed between userland
and the kernel, or between two userland programs, and to allow either
side's idea of the structure to change and become different then the
The way you do this is you characterize each field of the structure.
For example, take a look at /usr/src/lib/libcaps/caps_pwent.c.
So each side would have a caps array describing what it believes the
structure of the structure to be. When the sides differ, they would
be able to communicate *THEIR* caps array to the other side and the
other side would then be able to use the two caps arrays (its idea of
what the structure should be verses the other side's idea) to translate
the passed structure into the local format that it expects.
It is really that simple.
: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.
This has to do with the N:M threading concept. It has been abandoned
in favor of 1:1.
I think N:M is still desireable but what is needed is some sort of
official micro-threading API where the programmer has full knowledge
that a thread is a micro-thread, operating under different rules,
as part of a set of micro-threads opreating within a POSIX thread.
With an official micro-threading API the switch code could be done
entirely in userland. My idea of an API:
* Synchronous switching between the micro-threads inside a real thread.
* No automatic switching on blocking conditions, except under strictly
controlled circumstances (i.e. a particular API call to switch while
blocked on a read or write).
* 100% userland switching between the micro-threads running under a