just curious

[Matthew Dillon]

:Peter da Silva <peter at xxxxxxxxxxx> wrote:
:> you don't want to repeat the mistake of the Amiga where programs taking
:> advantage of things like this prevented better implementations later on.
:> What happens if the API changes so messages are copied... or *not* copied...
:> or it differs from implementation to implementation.
:
:  In which way are the messages changed? Do you refer to ln_Type or some
:  private data in an extended message?
:
:  Gunther

    I think a good example of how in-flight modifications can be bad is
    our current buffer cache implementation (struct buf), where interemdiate
    DEV layers mess around with random fields.  If you look at
    /usr/src/sys/sys/buf.h you will see the resullt..  the struct buf has
    b_driver1, b_driver2, b_saveaddr, b_ this , b_ that... all because
    multiple layers want to mess around with the struct buf structure during
    the I/O.  And over the years plenty of bugs have popped up due to that
    implementation.

    I am sure there will be a few special cases here and there, but generally
    chaining messages should be restricted to one of two forms:

    (1) An intermediate agent is able to handle the message.  It handles the
	message and returns it, not chaining or queueing to any more agents.

    (2) An intermediate agent needs to translate the message for further
	action.  It makes a copy of the message (possibly into a far more
	involved structure, consider the additional needs in a protection
	layer crossing!), translates the copy, and chains the copy on using
	its own reply port so replies would go back to this agent which 
	would translate the reply and adjust and return the original message.

    Now I know copying sounds bad, but for such small blocks of data as 
    typically comprise a message I really think the overhead is going to be
    in the noise especially considered our very light weight messaging model.
    Linear copies of small blocks of data on modern cpus are insanely fast.

							-Matt