usbatm : modprobe & rmmod

[Roman Kagan]

  Hi Duncan,

On Tue, 2005-01-25 at 12:25 +0100, Duncan Sands wrote:
> what do you want this flexibility for?  As far as I can see cxacru has no
> need for it.

Exactly.  Frankly, cxacru even needs less than is provided by usbatm2.
I just tried to think a bit more generically, e.g. considering the cases
with multiple interfaces.

> > 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.

The lifecycle here is managed by the core too (I didn't even had to
export udsl_{put,get}_instance).  However, the minidriver and the core
do call into each other, and the correct operation does depend on the
calling order, i.e. usbatm_init should be called only in minidriver's
probe, usbatm_atm_setup only in probe or heavy_init, and
usbatm_disconnect only in disconnect.  Dunno how much of a problem it
is.

>   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.

Right, provided the minidriver fits into this rigid framework.  cxacru
certainly does, but I've been wondering if Matthieu's eagle-usb does
too.

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

Unless I've screwed it up again, the minidriver shouldn't care: all the
refcounting is handled by the core.  OTOH the minidriver's heavy_init
can now take its time, without caring much about being quick to cancel.
And it doesn't look to be more complex than the synchronous shutdown.

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

Just in case: I meant the old cxacru adjusted to match the updated
usb_atm, not cxacru2 working with usbatm2 :).

Cheers,
  Roman.