DragonFly commits List (threaded) for 2006-07
Re: cvs commit: src/sys/bus/cam cam_xpt.c src/sys/bus/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_pass.c scsi_pt.c scsi_sa.c scsi_ses.c scsi_target.c src/sys/bus/firewire firewirereg.h fwdev.c fwmem.c fwmem.h fwohci.c src/sys/bus/iicbus iic.c ...
:does this mean that we're turning away from the message based communicati=
:on back to a monolithic execution, or is syslink just a different, better=
: (address space agnostic) messaging system, which can be used within the =
:kernel as well?
:i just got the feeling that with this is will be really easy to forward d=
:evices via network to other boxes, like the sound card or the usb stick f=
:rom a thin diskless client to the application server... right?
DEV, VFS, and even system calls are still messaged, but in a different
way then I originally envisioned.
My original vision was to encapsulate the arguments for a device, VFS,
or system call operation into a full blown message structure
(lwkt_msg), but have the default port dispatch simply make a direct
My new vision is to encapsulate the arguments in a structure that has
the ability to *become* a full blown mesasging abstraction, but which
does not start out as one. A direct call mechanism is *always* used
at the end-points, but the system link layer has control over the
functions being called so it has the ability to insert a new encoding
layer (and a decoding layer on the other side) which translates
the argument structure into a form that can be sent over a transport
link of some sort.
In my new vision a pointer to a descriptor (syslink_desc) is always
stored in the argument structure's header and this allows various
layers to identify the command out-of-band. For example, take a look
at the console device intercept code on line 266 of kern/tty_cons.c.
All the function vectors for a tty designated as the console collapse
into a call to cnintercept(). cnintercept() can deterine which command
(open, close, read, write, etc) was called by checking the ap->a_desc
pointer and do the right thing with it. Both VFS and DEV are now
beginning to use the syslink abstraction.
I abandoned the original methodology for two reasons. First, the
optimized 'direct call' case still had too much overhead due to
all the initialization required to set up the full blown messaging
structure. Secondly, I found that encapsulating the call in a
full blown message didn't actually provide any advantage for
the types of transport cases (userland VFS and inter-machine links)
that were likely to actually need a message. That is, regardless
of the structure used the arguments still would have to be encoded
for transport and decoded on the other end. The actual use of
a messaging structure like lwkt_msg did not make that job easier
and, in fact, added a lot of bloat that had nothing to do with
anything other then to support the lwkt_msg structure itself.
With the new methodology the direct call case has virtually no
additional overhead vs a direct argumented call. The arguments
are simply stuffed into a structure declared on the stack along with
one or two other pieces of data and a pointer to the structure is
passed to the next layer. System calls, VFS calls, and DEV calls all
now use this mechanism. The key to the new methodology is that the
function vector called can be replaced by the transport layer (not yet
designed) with a new function vector that does the argument
encoding/decoding, transport, and blocks (if necessary) waiting for a
This isn't to say that LWKT messages can't still be used... there's
no reason why the transport layer can't use them. But they are no
longer a required element... the transport layer will be free to
implement whatever methodology fits the particular type of transport
being implemented the best.