Re: [PATCH 1/2] usbatm: Increment module refcount when atm deviceis opened.

[Simon Arlott]

On 22/02/07 09:48, Duncan Sands wrote:
> What for?  Did you see any problems with the way it works right now?

It didn't make sense to be able to unload a module while it's actually in use, how does this work with automatic module loading/unloading (although I can't see how it's going to automatically load one of the sub drivers...)?


> How it works now is that if the module is unloaded while the device is
> in use, then the device is deregistered from the USB and ATM layers
> before the module unload completes.  Thus there should be no problem
> unloading the device at any moment.  
Ok.


> I'm guessing that you want this because of the better proc support you
> would like to add, which adds an extra callback into the module.

Actually it was partly because of the urb warning messages on unload... which the change doesn't even affect.


> This too should cause no problems as long as the appropriate tweaks are
> made to the shutdown code. I plan to make those adjustments, but I didn't
> find time yet - sorry.

I intend to export all the data via sysfs instead, since the current method of using proc (requiring several large enough read()s and no seeking) isn't very good and I can't see any way to improve it without caching the whole output from file open to close which atm doesn't support.

I was thinking that the MAC address/AAL stats should be removed from the proc output since they're already available from the atm devices proc file?


> PS: I plan to work on the drivers this weekend.

I don't expect to require any changes to usbatm to support sysfs, since the attributes should go with the usb device itself (and not the atm device). Perhaps there could be symlinks in each direction between the usb device and the atm device (like dvb/v4l do, e.g. atm:cxacru0 in the usb device)?

-- 
Simon Arlott

Attachment: signature.asc
Description: OpenPGP digital signature