[PATCH] info to atm layer about broken connection

[Duncan Sands]

Hi Stanislaw,

> > You still haven't explained why you want to prevent the module from being unloaded.
> > As I said early on, I want it to be possible to unload the module at anytime.  That's
> > not set in stone, but in order for it to be changed you need to supply a good reason.
> > Right now, the module can be unloaded at any moment; the module unload disconnects
> > the device, so the effect of unloading is the same as unplugging the device.  I'm
> > guessing that the things you don't like the current module unloading behaviour are
> > exactly the same things that annoy you when the device is unplugged.  Is that right?
> Well I rather think that try_module_get(subdriver_module) is standard behavior, 
> for example atm layer prevent unload usbatm module when there exist vcc 
> (functions __vcc_connect() and vcc_destroy_socket() in net/atm/common.c).
> So usbatm should also prevent unload subdriver module when is needed.

no, it is the ATM layer that should be changed.  A long time ago, in a galaxy
far far away there were no hotpluggable devices, i.e. devices which can appear
and disappear on the fly.  Then there was USB.  The ATM layer was written before
the USB layer, and does things in an out-of-date way.  It is standard for USB
drivers to be unloadable at any time - they just do a device disconnect then
unload.  After all, there is *no advantage* to not allowing module unload.  Your
argument is that: usbatm is unloadable because of ATM layer properties, thus
speedtch should be unloadable likewise.  But that is an empty argument.  I can
likewise say: USB drivers try to always be unloadable - the ATM layer should
be changed to be like USB.  Who is right?  To determine that, the question is:
is there any advantage to stopping module unload (no); is there any advantage
to allowing module unload (yes).

> > > My patch send NULL skb only when modem is physically disconnect form usb port.
> > 
> > It is impossible to tell the difference between a physical disconnect
> > and a logical disconnect (= module unload, usbfs ioctl, hotplug restart).
> > Your patch sends a NULL skb also when the module is unloaded for example.
> I didn't know usb_driver.disconnect can be called in usbfs or hotplug context,
> I thought only when module is unloaded or device removed.
> If we assume usb_driver.disconnect is called only in such situations,
> using try_module_get() prevent call usbatm_usb_disconnect when
> vcc list is not empty.

I understand what you are saying, but since the USB device can be unplugged
at a time when there are many vccs open, you have to be able to handle this
situation correctly anyway.  If you do handle it correctly, then there is no
longer any reason for disallowing module unload.

> Conclusion of the thread is using vcc_release_async(). 

Yes.  I never had the time to check how much work it would be to make
vcc_release_async work properly.  Maybe it is a hard problem.  Maybe
it is simpler to simply shove a NULL skb down.  I would like to
understand the situation perfectly before accepting any patches.

All the best,

Duncan.