On Wed, 28 Jun 2006, Kenshi Muto wrote: > > IMHO it is a udev issue. On an i386 unstable system I've just > > checked, it's loading parport and parport_pc, but not lp. This is a > > bog standard PIII with an Intel 440BX chipset. It must have detected > > the parallel port in order to load the parport bits, but for some > > reason didn't load lp.
The parallel port itself is in either PnP or ACPI tables, so the kernel notices it exists and fires up an coldplug event. Udev knows to load parport_pc in that case. In fact all "udev autodetection" works like this: it is kernel autodetection from the PnP-friendly PCI space, ACPI device tables, and PnPBIOS tables. So far, so good. But there is *NO* such provision for "lp", unless you told the kernel you wanted it built-in. "lp" is not a parallel port driver, it is a parallel port *protocol* driver, and as you probably know, there are other high-level drivers that can and do talk to parport and to parport-pc. So, forget the idea of the kernel autoloading it through coldplug. I believe that's the reason the udev maintainer will NOT do anything about it. I can't say he is wrong. If you need "lp", you either load it in through discover (which, unlike udev, has the task of finding out all high and low-level drivers that should be loaded in a system), load it in through /etc/modules, load it on an initscript, etc. One *can* "abuse" udev to load lp. The same way that one can abuse modprobe it self to also load lp if something tries to load parport. These are not sound solutions, they have serious drawbacks if the user does NOT want it to happen this way. IMO, the proper fix is to get discover to load lp if it finds parports, and ID all IEEE 1284 devices it can find, futher loading modules (like scanner protocol helpers or whatever). Just like it happens for USB and other kernel-helped hotplug buses. I.e. IMO the fix for this bug is to document the issue in NEWS.Debian as it is surprising CUPS users, and add discover to "suggests", plus fixing discover if it is not doing its job right. > Because any decettion daemons (udev, hotplug, discover, and so on) won't > care about lp module, I'd already added a module loading routine to Udev and Hotplug are *not* hardware detection systems. Either the kernel finds something and generate an event, or something must manually load the driver. The fact that you can program udev/hotplug to try to load "lp" if a parport port is detected by the kernel just means you could coax them to help you. Discover, OTOH, is the kind of utility that must load lp. If it is not doing so, it is high time to fix it. > the parallel backend of CUPS (26_modprobe.dpatch). IMHO telling users to either use discover, or to load the proper drivers would be best. > Although I don't perfectly understand why lp won't be loaded on > submitter's machine, I suspect this is because we've dropped some of root > privilege from CUPS. Again a good reason to use discover (and fix it to load lp to find out and ID IEEE 1284 parport devices). > I'm bit considering about loading lp module from CUPS init script instead > of from the parallel backend. Well, the initscript is a *much* better place to load it from, but make it configurable from /etc/default or somesuch if you do so. -- "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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
