usbatm : modprobe & rmmod

[Duncan Sands]

Hi Roman,

> I can't tell since the code to store the minidriver instance data hasn't
> hit CVS yet.  You'll probably need a release function for the
> minidrivers whose instance data can't be destroyed synchronously though,
> and call it in udsl_destroy_instance.

I didn't fix up cxacru yet, sorry.  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)?

> 1) modem driver instance owns a pointer to udsl_instance, rather than
> the struct itself.  It's allocated in udsl_instance_setup, and freed in
> udsl_instance_disconnect.

Yes, it is better to use a pointer (already done in new setup).  Probably
(in the old setup) the modem driver's data structure should be reference
counted, not the udsl_instance, and should destroy the udsl_instance when
it goes down. 

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

> In future it'll also need to call usb_{get,put}_interface to support the
> drivers like eagle-usb, which AFAICS uses different interfaces to send
> and to receive data.

It's simpler to just grab a reference to the entire usb device.  This is
already done in the usbatm code (both old and new versions).

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

> Even if this turns out to be a duplicated effort ending up in a waste
> bin, I'll consider it a good exercise in kernel programming for me :)

Exactly.  For example, everybody seems worried about how I'm changing
things, but there's nothing definitive about it: just seeing what I can
come up with.  If it turns out to be time wasted, well that's life.

Ciao,

Duncan.