On Tue, Dec 15, 2009 at 01:20:00PM -0800, Erik Nordmark wrote: > > The application would fail when the filter is removed since > suddently it would see unintelligable kssl crypto data on a socket > that previously delivered cleartext. > > Thus I think we need a better approach. > Doing better I_* emulation (all the "get" ioctls?) might be one way. > Finding applications that use I_* on sockets and fixing them would > be another way. >
I need to look into this a bit more. > >The missing piece of info here is that data_in_proc, which is called > >from the context of the application doing the read, process the data > >sitting in the socket queue. So if multiple datagrams are enqueued > >between reads, then the callback will see a b_next chain of mblks. > > Ah - looks like the document can be made more clear on that point. > Will do. > But does read() straddle b_next boundaries? (It didn't prior to > Volo, partly to handle urgent data correctly.) It clearly can't > straddle b_next boundaries for UDP. No, read() does not. But the data_in_proc callback processes all the available data, even if read() ends up copying a single datagram. Thanks, Anders _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
