usbatm : modprobe & rmmod

[Roman Kagan]

[ Something went wrong with the mail relay of my ISP, so resending this
  through another one.  Sorry if you receive it twice. ]

  Hi Duncan,

On Sun, 2005-01-23 at 15:45 +0100, Duncan Sands wrote:
> I didn't fix up cxacru yet, sorry.

Don't worry, I'll catch up as soon as the API hits the CVS.

>   Can you give me an example where the
> usbatm instance data can't be destroyed at disconnect time (excluding code
> run in the "heavy_init" kernel thread)?

Given the condition in braces - no, I can't.

> > 2) udsl_instance_{setup,disconnect} calls usb_{get,put}_dev (already
> > there) so that usb_atm can continue after driver instance is destroyed.
> 
> This sounds wrong.  Why would it want to continue after the driver instance
> is gone?
> 
> [...]
> 
> > 3) usb_atm refcount counts atm references only, and
> > udsl_{get,put}_instance become internal to usb_atm.  The drivers do
> > their own bookkeeping, if needed.
> 
> Sounds too complicated.  Once the ATM instance exists, it should live until
> the udsl_instance goes down.  I should point out that the ATM core already
> reference counts ATM instances, so it won't be freed until the last ATM
> connection is closed, even if the USB device died.  This is why a reference
> to the udsl_instance is taken by the ATM part: as long as the ATM device
> exists, the udsl_instance exists (and vice-versa actually).

Yep, I didn't realise the ATM layer provides the necessary
infrastructure (thanks to the ATM folks hiding part of the refcounting
stuff in inline functions in the headers, where I did't grep for
them :).

I eventually did it as Matthieu suggested, and I'm running it on my box
at the moment.

However, now that you've turned back to the modular structure in
usbatm2, which looks to me not only much saner than the monolithic
design, but also far superior to the original usb_atm, I'm all for
abandoning that effort in favour of your new approach.

Sorry for generating so much useless traffic,
  Roman.