Re: udev and /usr
Steve Langasek wrote:
On Fri, Sep 04, 2009 at 12:59:10AM -0400, Felipe Sateler wrote:
The issue was raised by the udev upstream maintainer along with the udev
package maintainers of the major distributions, who all agreed that this
configuration is not supported.
FYI, udev 146 ships usb-id and pci-id programs which read
/usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
udev itself does not care about the results of these programs but other
programs which used to use HAL may do, leading to subtle breakage.
Reading again your mail, I think we are discussing a inexistent problem.
You say that "some programs which use HAL may do" use /usr/share.
Hal also lives on /usr, so I don't see the problem either.
The problem is this:
- In udev 146 and above, a number of the stock udev rules call the
/lib/udev/{pci,usb}-db helpers to query the vendor name / product name
and and this information to the udev environment.
- These helpers work by parsing the pci.ids and usb.ids databases, which
have long had standard locations that are *not* in /lib (either in /usr
or in /var, both of which are allowed to be separate filesystems under
the FHS).
- Now that there are udev rules exporting this information, arbitrary other
components in the stack may come to rely on this information being
available (but we don't seem to know what components; the rationale for
this facility being added to udev so far is pretty opaque, though
whatever it is can't be good).
- These udev rules are applied from runlevel S, before /usr or /var are
guaranteed to be mounted. That means that any device which is detected
by the kernel before this point (such as non-hotpluggable PCI devices)
will have different information exported by udev depending on whether
/usr and /var are on the root filesystem.
I still can't fathom why someone decided that udev should be responsible for
translating PCI IDs and USB IDs into text strings. This smells of crazy.
I agree, also considering that AFAIK we have not the official names, thus from
time to time there are huge renames in the ids files. Sometime a company
changes the name and the ids file will change (addition or change of suffix
like "limited" etc; adding or replacing the new company name (on merges), ...
Some names contain non alphanumeric characters, which is annoying on device
names (they are properly quoted, but anyway).
Thus the use of ids file create not stable device names, and probably not
nice names. I really think numeric names are a lot better.
Anyway reading the id_usb:
* A unique USB identification is generated like this:
*
* 1.) Get the USB device type from InterfaceClass and InterfaceSubClass
* 2.) If the device type is 'Mass-Storage/SPC-2' or 'Mass-Storage/RBC'
* use the SCSI vendor and model as USB-Vendor and USB-model.
* 3.) Otherwise use the USB manufacturer and product as
* USB-Vendor and USB-model. Any non-printable characters
* in those strings will be skipped; a slash '/' will be converted
* into a full stop '.'.
* 4.) If that fails, too, we will use idVendor and idProduct
* as USB-Vendor and USB-model.
* 5.) The USB identification is the USB-vendor and USB-model
* string concatenated with an underscore '_'.
* 6.) If the device supplies a serial number, this number
* is concatenated with the identification with an underscore '_'.
Thus the use of name is only the third priority, and there are
3 additional fallbacks. Thus, IMHO, we don't need to worry much about
missing /usr/share on *some* environments.
Thus I think people who want a separate /usr can live lovely without
ids files (and probably they/me prefer numeric ids).
BTW the files are also included in the kernel, so we can use kernel
informations.
ciao
cate
Reply to: