usbatm : modprobe & rmmod
castet.matthieu at free.fr
Mon Jan 24 14:19:27 EST 2005
Duncan Sands wrote:
> Hi Roman,
> For me, the new approach was always about viewing speedtch, cxacru etc as
> "mini-drivers" that register themselves with the usbatm core. Since I never
> explained that (except to David on IRC), you couldn't be expected to know :)
> Also, the other thing I wanted to copy from usbnet was the trick of using the
> struct usb_device_id driver_info field to provide a light-weight way of registering
> mini-drivers. I initially copied the usbnet static registration because (1) it
> was quicker to do it that way, and (2) I couldn't really see the point of making
> each mini-driver into its own module. I was wrong about (2), and agree now that
> having each guy as its own module and doing dynamic registration is better than
> doing static registration. However, since I always knew that flipping between static
> and dynamic schemes was trivial (as proved by the rather small patch to do it), this
> was always a minor issue to me. As I said to David on IRC, I think you and he were
> repelled by the "huge heap of crud in a file" nature of usbnet, while missing the
> nice mini-driver aspect and the simple registration scheme (i.e. the driver_info trick,
> which is a bit hacky IMHO, but simple).
Ok, now the new model look saner and is quite similar than pci-ide (same
problem where pci~usb and ide~atm) ;)
I have still one complain : why driver info is still used ?
why not doing like pci-ide and give when registering struct
usbatm_driver and usb_interface ?
Also you need to provide a driver info in your struct usbatm_driver, for
the drivers that need it (a chipset could have different revision and
need loding a different firmware).
Also I don't understand the difference between bind & usbatm_atm_init
and atm_stop & unbind.
usbatm_atm_init could be done in bind if there is no heavy_init or in
atm_stop could be done in unbind.
More information about the Usbatm