Bug#375395: [Pkg-cups-devel] Bug#375395: cupsys: Printer stopped working after upgrade

[Henrique de Moraes Holschuh]

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