Thirumalai Srinivasan writes: > >Seems like the simplest fix for a lot of this brokenness is to simply not > >try to send the DL_DETACH_REQ. As per the bugs above, it seems like we've > >accidentally not been sending it for a while, and no one has complained. > >Further, the DLPI specification does not require that one do a detach > >prior to close -- so I think IP is within its rights to skip the detach. > >Thoughts? > > > > > I don't have the DLPI spec handy.
Well, of course you do: http://www.opengroup.org/onlinepubs/009618899/ > Is the optional part because some > drivers could be type 1 or is it optional even for type 2 drivers ? > Anyway I would not worry too much about it, making things simpler is better. > As more and more drivers become GLDv3, this is even less of an issue. The "optional" part is that there's just no sane way (in STREAMS) to deny a close(9E) operation. At the point where the driver's close entry point is called, the stream is mostly gone, and the user has packed his bags. There's little that the driver can do. It really does have to handle it, and that implies being able to close the device cleanly when in the DL_IDLE (attached and bound) state. Also, the "Allowable Sequence of DLPI Primitives" points this out: The close of a stream is considered an abortive action by the DLS user, and may be executed from any state. The DLS provider must issue appropriate indications to the remote DLS user when a close occurs. For example, if the DLPI state is DL_DATAXFER, a DL_DISCONNECT_IND should be sent to the remote DLS user. The DLS provider should free any resources associated with that stream and reset the stream to its unopened condition. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> 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
