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

[Matthew Dillon]

: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?
:
:good work!
:  simon

    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
    call.

    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
    response.

    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.

						-Matt