User API still a goal?

[Matthew Dillon]

: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:
:...
: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
    other side.

    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 
      posix-thread.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>

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