From: Duncan S. <bal...@fr...> - 2005-06-22 21:57:35
|
> > > > > > The speedtouch is an USB ATM modem - as such it can be unplugged > > > > > > at any time. If the modem is disconnected, should the driver call > > > > > > the ->push method for any open VCs with a NULL skbuff? I'm looking > > > > > > for a way to tell the higher layers that the modem has gone and is > > > > > > not coming back! I see that pppoatm shuts itself down when a NULL > > > > > > skbuff is seen. Who is responsable for sending such a skbuff - the > > > > > > low level driver or a higher layer? > > > > > > > > > > its not clear what the right behavior should be. there should > > > > > probably be an explicit mechanism for detaching the atm protocol. > > > > > the passing of the NULL is typically handled during vcc close which > > > > > must be handled by user space some of the atm drivers sleep during > > > > > close. > > > > > > > > > > when your driver detects hardware removal i guess it should go > > > > > through its vcc's and close them (or atleast mark them !READY) > > > > > so that all pending and future operations on those vcc's fail. > > > > > > > > Hi Chas, thanks for writing. My driver certainly marks them as not > > > > ready: all attempts to transmit a skbuff on one fail with -ENODEV. > > > > Do you mean something more than this when you talk of closing a > > > > vcc? > > > > > > so i guess vcc->dev is getting set to NULL at some point. however > > > this will also prevent from vcc_release() from doing the h/w > > > independent part of the close operation -- see vcc_destroy_socket(). > > > perhaps vcc_destroy_socket() could be more clever about the operations > > > that can be performed when vcc->dev == NULL. > > > > Hi Chas, my driver generates the -ENODEV in its send method. vcc->dev is > > not NULL, it is vcc->dev->dev_data that is NULL. > > when the usb device is unplugged it should mark the vcc's as not ready > by going through the list of active vcc and issue a vcc_release_async() > on the vcc's. this should get any application using the vcc's to wakeup > and close. you will need to handle dev->close() being called when there > is no hardware to complete the hardware side of the close. this should > let the protocol close (the NULL skb passing) complete and then let > the vcc close. Hi Chas, I hope to finally implement this shutdown logic. If I understand right, when the modem is unplugged I should go down the list of all open vcc's and for each one I should call vcc_release_async(vcc, -EPIPE); This will propagate -EPIPE up to the sockets layer. Does it force the vcc to be closed, or just give a hint to userspace by binging the application on the head with a EPIPE? If an application insists on not closing it's socket, does that mean the vcc will continue to be open? Anyway, after (before?) vcc_release_async should I send a NULL skb via the vcc's push method? What additional effect does that have exactly? I'm confused about the role of each of these operations... Thanks a lot, Duncan. |