Anders Persson wrote:
The mechanism I was looking at was the one that removes specific
packages before installation (pkgrm.lst).
OK, I'll have to go read about that.
What is the impact of issuing such ioctls work on a kssl socket today?
With kssl as a socket filter it would cause the socket to stop
functioning if the effect is to remove the filter.
Today kssl would continue to work, and as a filter it would be
disabled. But is application failure a suitable alternative?
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.
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.
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.
Erik
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
