speedtch usbatm.h,1.4,1.5 usbatm2.c,1.13,1.14

Roman Kagan rkagan at mail.ru
Tue Feb 8 05:37:18 EST 2005


  Hi Duncan,

On Mon, Feb 07, 2005 at 11:43:16PM +0100, Duncan Sands wrote:
> [...] this kind of
> thing always happens when a driver creates files.  One way to do things is to hold
> a reference to the struct usbatm_data instance as long as the files are around.
> Access to minidriver data is protected by a lock that lives in this instance.
> During disconnect, the lock is taken and the pointer to the minidriver data
> is cleared.  When reading from a file, the lock is taken before copying minidriver
> data to the file.  If the pointer is NULL, then the file operation is made to fail.
> There is no need to take a reference to the _minidriver's_ data.

OK, I get the idea.

> [...] Anyway, the core can exploit
> the minidriver's methods (and, implicitly, data) from the moment a minidriver
> is registered, but not after a minidriver is deregistered.  That's how a lot of
> the kernel does things, and it is simple and clear.

Well, the drivers which manage their state with the help of the driver
core are required to provide .release method.  OTOH there's no reason
for usbatm to mess with the driver core at the moment, as the
relationship with the minidrivers is rather simple.

> In short, if you want to argue against waiting for the kernel thread to exit (please
> feel free to do so), or holding onto the minidriver's data, you need to argue against
> that model.

That's undersood.

Anyway the current usbatm just works, so I suggest to stick with it for
now and see if causes any problems, in which case resurrecting the async
cleanup version won't be too hard and won't involve user-visible
changes.

Otherwise we'll miss 2.6.11 (or have we already?) which will be a pity,
especially in view of the problems with lifetime rules in the usb_atm in
2.6.10.

I have a few unimportant patches pending for cxacru (will commit them
today), but overall it seems to be in a pretty good shape to start being
beaten by a wider public.  IMO so is usbatm core.  speedtch needs to
catch up; I could do that but I don't have the hardware to test it.

Do you think we still can make it slide in 2.6.11?

Cheers,
  Roman.



More information about the Usbatm mailing list