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 20:08:58 +0200

Matthew Dillon wrote:
: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.

Reading through libcaps, it seems that one part of it defines a compact serializing format, but I don't get the exact format yet due to missing documentation ;-)

Hm, are you defining some kind of template, which defines at which
position a specific value (of a specific type) is to be placed?  So, you
don't send messages using a serializing format, instead you exchange the
message format definition so that the client is able to generate binary
messages herself. Is that the idea?

The advantage over a serializing format, i.e. packing und unpacking, is

  * Only the client has to encode the message (from a template format),
    as the message format is always native to the kernel.

  * The client can have an optimized (compiled) encoder, as long as
    the kernel doesn't change the message format.

On the other hand, I think it (libcaps) is more complex (and less
flexible) than plain old serialization.

Well, your caps idea reminds me to how L4 (the micro kernel) defines
it's ABI.  They do it using IDL and a compiler which generates optimized
stub code. Just to mention that L4 uses messages very heavily. The
difference is that caps can be optimized at compile time (like IDL), but
gracefully fall back if the caps definitions have changed at runtime,
without the need to recompile the application.



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