usbatm : modprobe & rmmod

[Roman Kagan]

  Hi Duncan,

On Tue, 2005-01-25 at 13:42 +0100, Duncan Sands wrote:
> > 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.
> 
> I guess the main problem is that I don't like it :)

Well that's a good enough reason to discard it, since you're the
maintainer.  Besides I agree that depending on the minidriver writer to
follow the exact calling sequence sucks.  However I'd like to experiment
a bit more with it, maybe I can come up with a better solution.

> Good question.  About the rigidity (which is the flip side of simplicity and
> regularity): for me the main question is: does it enhance maintainability/
> correctness, or does it encourage hacks to work around it?  If it pushes
> minidriver authors towards a clean design, and reduces the chances of writing
> wrong code, then it is a good thing.  If it is rigid in the wrong way, making
> it impossible to have minidrivers work without hacks to get around the usbatm2
> setup, then that is bad.  The problem is that it is hard to judge this kind of
> thing in advance.  As more minidrivers get written, it should become clearer.

Couldn't agree more.  However we may fall into a chicken&egg problem:
until the API is stable, people are reluctant to write new drivers.

> My feeling is that the usbatm2 design is basically sound.

I don't say the opposite.  I just felt it was more natural to write a
usual USB driver with callouts to the library module rather then a
framework-specific minidriver which may want to do something beyond the
framework boundaries (no, I don't have an example :) that's just a
feeling).

> I had two things in mind when I made it synchronous: (1) future writers of
> minidrivers, maybe with more complicated heavy_init routines than we have,
> are less likely to write racy code with a synchronous setup (you could
> retort that they are more likely to write code that holds up the khub thread
> for a long time in the synchronous setup, by not exiting their heavy_init
> thread promptly); (2) with the synchronous setup it is possible to unload
> the kernel module at any time, even during the heavy_init (with asynchronous
> init, you have to take a module reference which blocks module unloading).

I buy neither (1) nor (2) :)  In case you're interested, my reasoning to
stay with asynchronous version was your (1) inversed plus the fact that
I needed a cleanup callback anyway.

Cheers,
  Roman.