libusual interface [was Re: libusual and ub]

Pete Zaitcev zaitcev at redhat.com
Thu Dec 15 05:10:08 UTC 2005


On Wed, 14 Dec 2005 22:18:22 -0500, Bill Nottingham <notting at redhat.com> wrote:

> 1) It breaks all 'normal' probing for devices, as the device tables
>    are removed from the module. You have to hardcode one module or
>    the other if you're running in an environment where the modules
>    aren't in 'normal' locations

I'd like to see some concrete details or perhaps an example of a breakage.

> 3) If you want to change which one you use, since libusual is built-in,
>    you have to reboot. This seems to be sort of a non-starter.

Adding a sysfs method is on my list. It's not hard. I simply forgot
that Fedora ships with USB built-in.

> a) we blacklist one of the drivers
> b) we don't build one of the drivers
> c) we turn off automatic binding, and use the bind/unbind features
>    to handle it

Only (c) is somewhat viable, if we are to have ub at all.

I saw the discussion on linux-pcmcia which gravitated towards bind/unbind,
but the circumstances of it, shall we say, are fisy.

Bind/unbind does have some strong points, which revolve around not needing
a good will of a driver maintainer when you want to give his driver a boot
in the ass. However, while very useful for people who like to hack in a
private CVS, this capability gives us exactly nothing in case of ub and
usb-storage.

As one poster insightfuly observed in that thread, if Roskin's driver
and normal driver were merged, there would've been no problem.

This brings us to the real meat of the discussion:

> 2) It circumvents the normal hotplug mechanisms... while you're still
>    getting events to userspace about the USB device add, the kernel
>    is (effectively) handling the event behind your back.

Libusual does not circumvent shit. I guess some education is needed here,
so please bear with me.

Unlike the pcimcia wireless and its tug-of-war, there's only one USB
storage driver here, as far as hotplug is concerned. It happens to be
called libusual, but I could have called it "grand-unified-usb-storage"
or "pot_sex_tux_happy". Do not get hung up on the "lib*" prefix.
When libusual is enabled, ub and usb-storage do not exist. Everything
regarding the hotplug _including_ alias matching, module locations,
etc. etc. works as before. Everything. No circumvention at all.

Now, as it happens, libusual loads some other kernel modules to do
the work. It's easier to code that way. I could have simply used
the #include directive to accomplish the same effect and nobody
would be the wiser... right? Well, except the code bloat, because
with the current libusual you often have just one back-end loaded.

But in fact, #include is how it was originally. The ub started its life
as a mode for usb-storage ("threadless" storage). And Matt Dharm would
approve that just fine, trust me. But it became apparent very quickly that
there was very little code sharing between the two, so I thought it
appropriate to split them. Maybe that was a mistake politically.

If you want to poke at implementation details beyond libusual, observe
that ub is not a replacement for usb-storage. I have them loaded
simultaneously and they do drive different devices simultaneously.
Plug TEAC CD-210PU into a Rawhide system biased to ub and you'll see.

The libusual is far from being the only driver which has components.
Just look at md, for instance.

I hope that clears things somewhat. But if you have any concrete examples
of a breakage, by all means bring them up (e.g. what happens in initrd).

-- Pete




More information about the devel mailing list