Re: switching to kernel 2.6 - manual "modprobe lp" to dev /dev/lop
Mark Fletcher wrote:
Daniel B. wrote:
In trying to switch to kernel 2.6(.8) and udev on Sarge, I found that
device node /dev/lp0 (for a parallel-port printer I have) doesn't get
created unless I manually run "modprobe lp".
Is the printer (and/or parallel) port supposed to be recognized
automatically and is /dev/lp0 supposed to be created automatically?
Or is it expected that module lp needs to be loaded explicitly
(in /etc/mod...whatever).
...
The only explanation I can immediately think of for this is that in your
previous kernel, parallel port support was compiled into the kernel
whereas in your 2.6.8 build you have built it as a module.
No, I don't think it's that. (All my kernels (my previous patched
2.4.18 configured like Debian's 2.4.18, Sarge's 2.4.27 kernel, and
Sarge's 2.6.8 kernel) had/have parallel port and lp support built
as modules. I think things changed only when I went to 2.6.8 and
started using udev)
(By the way, note that I didn't say that the parallel-port modules
weren't loaded: modules "parport" and "parport-pc" are loaded; it's
module "lp" that isn't loaded automatically.)
Actually, I think part of the difference might be that before udev,
the device node (/dev/lp0) already existed, so when lpd tried to
access /dev/lp0, that would trigger the kernel to load module lp.
Now, since udev doesn't create the device node /dev/lp0 until the
module is loaded, lpd startup can't trigger loading the lp module
(and lpd fails because there is not /dev/lp0).
My real question is whether udev (or module loading) is supposed to
be loading module "lp" automatically (and therefore something's
wrong with it on my machine).
*In particular*, I wonder if it's simply that the kernel can't know
what's attached and listening to the parallel port (presumably
because there's no standard probing protocol for parallel-port
devices), so it can't know to load the lp module (which would trigger
udev to create /dev/lp0), and therefore manually forcing the lp
driver into the kernel (whether by loading the module or reconfiguring
and recompiling the kernel) is the expected way to get things to work.
> I am assuming
> you built your kernel from source and didn't take a pre-compiled binary
> one here -- if you didn't of course you won't KNOW what's modular and
> what's not -- just one of the many excellent reasons for building your own.
Actually, it is pretty easy to know what's a module--Debian kernel image
packages include the kernel configuration file used to compile it (and
there's all the module files in /lib/modules/<version>/...).
In any case, adding lp to the list of modules to load on startup in the
file /etc/modules will fix it --
Right. I'm just wondering if that's the "right" way or if there's a
better way to fix it ...
> but if you know you will always want
parallel printer support on every boot you probably should have compiled
lp into the kernel -- hardly a disaster but it's worth considering
carefully what goes in the kernel and what gets compiled as a module so
you avoid confusions like this one.
... well, within the realm of leaving it as a module.
Daniel
Reply to: