🚀 go-pugleaf

Well, you can actually do almost anything you want between a socket()
and a connect() or accept() call, by using (or abusing) the
setsockopt() system call at the SOL_PROTO level (yes I know this
doesn't work in 4.2 as distributed).  This is how we set the stream
type and EOM bit in our XNS implementation.

As for reading and writing arbitrary sized messages, this would take
some hacking.  The kernel really wants to move all the data into mbufs
before passing it to (or receiving it from) the protocol level.  This
makes the protocol code cleaner, since it need not deal with sockbufs.

It might be nice if the write code told the protocol level code what
uio_resid was after it put the data into the mbuf chain that goes with
the PRU_SEND request; this would at least let the protocol estimate the
amount of data left to be moved.  A new mbuf field on the input side
for holding the amount of data yet to be received might also then be
useful.  Of course, this means you'd have to pretend that your atomic
protocol was actually a stream:  more kludgery.  Oh well.

In any case, it is clear that the existing code is not up to dealing
with multi-kilobyte sends and receives.  Pick a real solution and try
it, but please don't store funny integers in mbuf pointers!  (I removed
the "m_act = 1" kludge for atomic protocols when we implemented XNS.
I was amused to discover that Sam Leffler also removed the same kludge
from the UCB kernels at about the same time.  Isn't there some quote
about minds that applies? :-) )
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland