[EMAIL PROTECTED] writes: > In addition, there's no guarantee that something along the way, > be it a STREAMS module or pfhooks function or something else > won't park the mblk off to the side somewhere and come back > to it later. This may happen to one mblk or many, so the driver > may run out of preallocated buffers...
True, but one remote possibility here might be to make putq() scrub these things away. In other words, have putq(9F) check for an 'indirect' mblk (one that points to a dblk with this special tied-down hardware dependency) in the chain, and if it's one of those, then do copyb(9F) on each special one or copymsg(9F) on the whole thing, and free the original. This guarantees that inbound messages are either handled promptly, or they're freed to recover resources, or that any queuing is done is in some weird non-STREAMS code that someone dreamt up and we can't control and is unlikely anyway. (You could get fancier and do the scrub only after it's been on a queue for some period of time, but that seems both much harder and unnecessary.) Notably, that tied-down mblk problem happens with user-space applications. You can open a driver with snoop, ^Z the snoop process, then walk away. What should the driver do in that case, when all its receive resources get tied up in service of buffers sitting on the STREAMS read head queue for days or weeks? -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
