On Wed, 28 Jun 2006, Martin-Éric Racine wrote: > We have too many hardware detection layers and none of them able to see > the full picture. Even worse, as witnessed in this particular case, they > all fail at detecting something as simple as the printer driver. > > Anyhow, udev and discover duplicate each other in several way; they > ought to be merged the same way that udev integrated hotplug.
They *will* and *are* to have some overlap. Here's the charter for each utility as far as I know: 1. Discover - Probe, load device drivers and enable **devices** so that they are fully usable for the rest of userspace ** Device discovery and autodetection is in its charter ** 2. Udev - Async event handler for the kernel event interface, /dev policy enabler, event-driven async userspace enabler ** Any action that is based on an kernel event is in its charter ** > The way this could work: > > 1) detect hotplug events. Kernel. This is working wonderfully. Note that parport is NOT hotplug, and also not that hotplug != coldplug, so don't get the two mixed with each other. > 2) detect other hardware drivers. AKA coldplug. Kernel and Discover for most devices (stuff like raid arrays and crypto filesystems also go here, and are handled by other stuff that isn't discover). The kernel won't do it for modules. > 3) detect peripherals attached to ports drivers loaded at 1 and 2. This is the layer where "lp" loading is currently broken... I'd call this layer "loading of protocol and extra higher-level drivers". > AFAIK 1 and 2 are already handled by udev, while discover partially > handles 2 and 3. Udev does not, should not, and is not handling "hotplug event detection". It *answers* to hotplug events that the *kernel* generated (or something else did, I suppose). Udev is an event handling *hub*, and not an event *source*. I suppose, as a proper intelligent event handling hub, udev is capable of generating new events as an *answer* to an event it is handling, but that's sane and not a problem. IMO we can get the layer 3 (protocol driver loading) into udev without going out of its intended scope, but not all of it: if it is an action that is not traceable to an event that is already generated, something *else* than udev will have to generate the event to trigger the protocol driver loading. If, and only if we do it properly, it is sort of fine to teach udev to RUN+="modprobe lp" (and then handle anything lp on the event generated by the kernel when it DOES load and activate lp), or to teach udev *for now while we still have static device numbering and kernel autoloading of modules based on it* to "MAKEDEV --<some new switch> /dev/lp". But there is no way in heck we should have any such "layer 3" udev rules in an normal application package! Either they go in udev's package (doubtful), or in the package that provides the protocol handler in question (in this case, the kernel-image package), or in an auxiliary package (udev-foo-rules) that gets these rules together. And it would require extending MAKEDEV if we are going to create device nodes. It may be also fine to extend discover to instead of being a coldplug-only thing, to also hook into udev to analyse new events and does the above. I am now in doubt of which is the best way to handle it, the "fix discover to load lp in the first place, AND extend it to plug into udev and do also extra work as a hotplug event generator in answer to some events" seems like the best answer. But it is also far more complicated. IMO it is time to ask the discover and udev maintainers directly for their input on this issue. What do you guys think? > IMHO, this is a debian-boot issue, not an application issue. You are correct, this is *not* an application issue, and it is NOT to be fixed as anything but a temporary stop-gap measure in the CUPS initscripts. We need to fix it properly (at which time CUPS will have to be modified to not be modprobing lp anywhere, anymore). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
