usbatm : modprobe & rmmod

[Duncan Sands]

Hi Roman,

> Given that the main development now concentrated on usbatm2, I decided
> to give usb_atm another try, just for the sake of completing the
> experiment.
> 
> I've tried to do what Matthieu suggested and marry the best of the two
> approaches: the control and flexibility of the former and the subdriver
> infrastructure facilitating the code sharing of the latter.

what do you want this flexibility for?  As far as I can see cxacru has no
need for it.  Also, I don't see how it gives you more, except maybe in the
case when you need to work with multiple interfaces (usbatm2 is a bit
awkward there right now).  On the other hand, maybe I'm misunderstanding.
If you would like to register methods at device connect time and deregister
them at device disconnect time, well in fact that is fairly OK with me.

> In a few words, the subdriver now registers a struct usbatm_driver with
> usbatm_init at probe time, and, once the device is ready for ATM, calls
> usbatm_atm_setup to create an ATM device.

What I don't like is that the driver lifecycle is partly managed by the core,
partly by the minidriver, with each of them calling back into the other.  In
usbatm2, the core controls the whole lifecycle, and simply calls the minidriver
at each significant moment (bind, atm_start, atm_stop, unbind.  This makes
things extremely regular and the lifecycle simple to understand.

> The subdriver must provide a ->cleanup function to be called when the last
> reference to it is dropped.  Also it may call usbatm_heavy_init to do
> lengthy initialization, in which case it must provide a ->heavy_init
> function, which will be run in a separate thread.
> 
> All the bookkeeping is done in usb_atm, including the refcounting for
> the heavy_init thread (I didn't dare to switch to synchronous thread
> shutdown).  I also had to play a little trick to make the ATM layer own
> the reference to the subdriver, rather than to usb_atm.

I think synchronous thread shutdown will work fine, and it simplifies
thinking about driver and the writing of minidrivers (race conditions).

> The updated cxacru seems to behave well under various conditions,
> including disconnect, module unloading, etc.

Great!
 
> Please feel free to comment (or to ignore :).

Duncan.