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

[Henrique de Moraes Holschuh]

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