Help wanted with parallel port rule

Help wanted with parallel port rule

[Barrie Stott]

I have a Laserjet 4l printer on my parallel port and am having trouble
creating a udev rule that will deal with it. Below I give my reasons
for what I have done in the hope that someone can tell me where I am
going wrong. My main source of information is `Writing udev rules' by
Daniel Drake and am using a GNU/Linux system running Debian Lenny.

1. I knew that I had modules parport and parport_pc by looking as the
output from lsmod so I ran:

	ls -lR /sys | grep 'parport:\|parport_pc:'

The complicated grep parameter merely restricts the output to desired
directories and gave as result:

/sys/bus/pci/drivers/parport_pc:
/sys/bus/platform/drivers/parport_pc:
/sys/bus/pnp/drivers/parport_pc:
/sys/module/parport:
/sys/module/parport_pc:

2. I chose the smallest of these as simplest to type and ran:

	udevinfo -a -p /sys/module/parport

`Writing udev rules' says that there should be no initial `/sys' but I
get the same result with and without it. The essential result from
running udevinfo was:

  looking at device '/module/parport':
    KERNEL="parport"
    SUBSYSTEM="module"
    DRIVER=""
    ATTR{refcnt}="1"
    ATTR{initstate}="live"

3. I created the following udev rule from this:

KERNEL="parport", SUBSYSTEM="module", DRIVER="", ATTR{refcnt}="1", \
ATTR{initstate}="live", SYMLINK+="ljet4l"

I included everything from udevinfo output in case omitting something
invalidated the rule. My hope after using the rule was to have a
symlink ljet4l somewhere under /dev knowing that there wasn't one
already.

4. To test my rule I ran the following (as root) but no ljet4l
appeared under /dev as a result.

	udevcontrol reload_rules; udevtrigger

This is essentially the first udev rule I've ever written so I am not
dismayed that it is faulty. I just need someone to tell me which part
of what I've done is wrong and what it should be instead, the aim
being that eventually I get a working rule.

Barrie.


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Help wanted with parallel port rule

[Kay Sievers]

On Nov 29, 2007 9:48 AM, Barrie Stott <G.B.Stott@bolton.ac.uk> wrote:
> I have a Laserjet 4l printer on my parallel port and am having trouble
> creating a udev rule that will deal with it. Below I give my reasons
> for what I have done in the hope that someone can tell me where I am
> going wrong. My main source of information is `Writing udev rules' by
> Daniel Drake and am using a GNU/Linux system running Debian Lenny.
>
> 1. I knew that I had modules parport and parport_pc by looking as the
> output from lsmod so I ran:
>
>         ls -lR /sys | grep 'parport:\|parport_pc:'
>
> The complicated grep parameter merely restricts the output to desired
> directories and gave as result:
>
> /sys/bus/pci/drivers/parport_pc:
> /sys/bus/platform/drivers/parport_pc:
> /sys/bus/pnp/drivers/parport_pc:
> /sys/module/parport:
> /sys/module/parport_pc:
>
> 2. I chose the smallest of these as simplest to type and ran:
>
>         udevinfo -a -p /sys/module/parport
>
> `Writing udev rules' says that there should be no initial `/sys' but I
> get the same result with and without it. The essential result from
> running udevinfo was:
>
>   looking at device '/module/parport':
>     KERNEL="parport"
>     SUBSYSTEM="module"
>     DRIVER=""
>     ATTR{refcnt}="1"
>     ATTR{initstate}="live"

This is just the kernel module, not a device you can access from userspace.

> 3. I created the following udev rule from this:
>
> KERNEL="parport", SUBSYSTEM="module", DRIVER="", ATTR{refcnt}="1", \
> ATTR{initstate}="live", SYMLINK+="ljet4l"

Matching on the refcound of the module sounds pretty funny. :)
But again, where should the symlink you request point to? There is no
device node.

> I included everything from udevinfo output in case omitting something
> invalidated the rule. My hope after using the rule was to have a
> symlink ljet4l somewhere under /dev knowing that there wasn't one
> already.
>
> 4. To test my rule I ran the following (as root) but no ljet4l
> appeared under /dev as a result.
>
>         udevcontrol reload_rules; udevtrigger

Udevtrigger handles only devices, modules will not be coldplugged.

> This is essentially the first udev rule I've ever written so I am not
> dismayed that it is faulty. I just need someone to tell me which part
> of what I've done is wrong and what it should be instead, the aim
> being that eventually I get a working rule.

I guess, you are looking for a device like /dev/lp0? You probably don't
need any rule or custom symlink for it.

Kay

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Help wanted with parallel port rule

[Barrie Stott]

Many thanks, Kay, for the reply.

On Thu, Nov 29, 2007 at 12:09:18PM +0100, Kay Sievers wrote:
> On Nov 29, 2007 9:48 AM, Barrie Stott <G.B.Stott@bolton.ac.uk> wrote:
> > I have a Laserjet 4l printer on my parallel port and am having trouble
> > creating a udev rule that will deal with it. Below I give my reasons
> > for what I have done in the hope that someone can tell me where I am
> > going wrong. My main source of information is `Writing udev rules' by
> > Daniel Drake and am using a GNU/Linux system running Debian Lenny.
> >
> > 1. I knew that I had modules parport and parport_pc by looking as the
> > output from lsmod so I ran:
> >
> >         ls -lR /sys | grep 'parport:\|parport_pc:'
> >
> > The complicated grep parameter merely restricts the output to desired
> > directories and gave as result:
> >
> > /sys/bus/pci/drivers/parport_pc:
> > /sys/bus/platform/drivers/parport_pc:
> > /sys/bus/pnp/drivers/parport_pc:
> > /sys/module/parport:
> > /sys/module/parport_pc:
> >
> > 2. I chose the smallest of these as simplest to type and ran:
> >
> >         udevinfo -a -p /sys/module/parport
> >
> > `Writing udev rules' says that there should be no initial `/sys' but I
> > get the same result with and without it. The essential result from
> > running udevinfo was:
> >
> >   looking at device '/module/parport':
> >     KERNEL="parport"
> >     SUBSYSTEM="module"
> >     DRIVER=""
> >     ATTR{refcnt}="1"
> >     ATTR{initstate}="live"
> 
> This is just the kernel module, not a device you can access from userspace.

I've reread the Writing Udev Rules document and you're right. His
emphasis like yours is on `device' and he searches sysfs only for
directories containing a dev file. Unfortunately, I took that to be an
example rather than a rule.

> > 3. I created the following udev rule from this:
> >
> > KERNEL="parport", SUBSYSTEM="module", DRIVER="", ATTR{refcnt}="1", \
> > ATTR{initstate}="live", SYMLINK+="ljet4l"
> 
> But again, where should the symlink you request point to? There is no
> device node.

I was hoping that udev would give me the default name as the WUR paper
says under Basic Rules: `Note that we did not specify a device node
name, so udev uses the default.'.

> Udevtrigger handles only devices, modules will not be coldplugged.

I'd not realised that. Would switching on the printer trigger udev? Is
there any way to mimic/achieve coldplugging apart from a reboot? Could
a udev restart or reload?

> I guess, you are looking for a device like /dev/lp0?

Yes. My initial attempts were to get udev to create it but without any
success. I did find a file, links.conf, that I modified to allow
/dev/lp0 to be made but I found no way to get /dev/lp0 using rules. My
main problem here is that I don't know what, in /sys corresponds to
lp0 in /dev and udev would need that information.

> You probably don't
> need any rule or custom symlink for it.

I don't *need* a rule; I can use links.conf. However, with an initial
comment in links.conf saying `This file doesn't exist', I get the
feeling it's a back door: something we'd rather not talk about. I
would love to know how to create /dev/lp0 without using links.conf.

Thanks again, Kay.

Barrie.


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Help wanted with parallel port rule

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 3075 bytes --]

On Thu, Nov 29, 2007 at 02:49:38PM +0000, Barrie Stott wrote:
> I've reread the Writing Udev Rules document and you're right. His
> emphasis like yours is on `device' and he searches sysfs only for
> directories containing a dev file. Unfortunately, I took that to be an
> example rather than a rule.

You can write udev rules that trigger on events other than device adds.
(For instance, the rule that runs modprobe when a uevent with a
MODALIAS happens is one of that type.)  However, you can't create a
symlink in those rules, because there's nothing for the symlink to
point to.

> I was hoping that udev would give me the default name as the WUR paper
> says under Basic Rules: `Note that we did not specify a device node
> name, so udev uses the default.'.

Not on a uevent for the "parport" module.  :-)

> > Udevtrigger handles only devices, modules will not be coldplugged.
> 
> I'd not realised that. Would switching on the printer trigger udev?

Not if it's connected to the parallel port.  The hardware doesn't
support hotplugging anything (AFAIK anyway), so I don't think it's
possible for udev to get an event when the printer turns on or gets
plugged in.  Besides, the lp0 device file is usable whether there's a
printer on the other end of the plug or not (even if there's nothing on
the other end of the plug).

The lp0 device file should show up when you load the lp module (I
think), although you'll need the parport and parport_pc modules as well.
You may want to try loading all of them if you don't have the file,
though I think lp depends on both parport* modules.

(Unless recent kernels have changed that?  I don't think so, but I don't
know for sure.)

> Is
> there any way to mimic/achieve coldplugging apart from a reboot? Could
> a udev restart or reload?

If there's a /sys/class/printer/lp0/dev file, then udevtrigger should
work OK, as long as you don't use something like --subsystem-match.

The /sys/class/printer/lp0 directory is what you probably should have
started with, but that's fine too.  :-)  Actually, finding that from
udevinfo would have been possible too, with something like:

udevinfo -q path -n /dev/lp0

but whatever.

> Yes. My initial attempts were to get udev to create it but without any
> success.

By default udev should create lp0 on its own without any help.  You
shouldn't have to write a rule unless you need a custom symlink name or
something like that.  (And if the file doesn't exist, then writing a
rule won't help either.)

> My main problem here is that I don't know what, in /sys corresponds to
> lp0 in /dev and udev would need that information.

See the above udevinfo incantation.  ;-)

> > You probably don't
> > need any rule or custom symlink for it.
> 
> I don't *need* a rule; I can use links.conf.

What I think Kay meant is that udev should be creating /dev/lp0 without
any help from rules at all.  If it doesn't do that, then there's some
other kind of problem here; perhaps not all the modules are loaded or
something?


[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 309 bytes --]

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Help wanted with parallel port rule

[Barrie Stott]

I'm very grateful for your reply. There's a lot here to get to grips
with as there is with Kay's email. The main thing for me at present
is the following:

On Thu, Nov 29, 2007 at 01:18:04PM -0500, Bryan Kadzban wrote:
> The lp0 device file should show up when you load the lp module (I
> think), although you'll need the parport and parport_pc modules as well.
> You may want to try loading all of them if you don't have the file,
> though I think lp depends on both parport* modules.

I've never come across the lp module before. `modprobe lp' brought me
/dev/lp0 that I didn't have before without using links.conf. A lot of
other things are dropping into place and I want to play with these a
bit before getting to some of the other things you said.

> What I think Kay meant is that udev should be creating /dev/lp0 without
> any help from rules at all.  If it doesn't do that, then there's some
> other kind of problem here; perhaps not all the modules are loaded or
> something?

How's that (not all modules loaded) for hitting the nail on the head?
I didn't have /dev/lp0 and couldn't find a good way to get it. Now it
comes by using `modprobe lp' and vanishes again with `rmmod lp'. And I
can use udev info with /dev/lp0 now as well. Things are looking up.

Thanks again; you've made me very happy.

Barrie.


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Help wanted with parallel port rule

[Bryan Kadzban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

(CC'ing the new list as well.  I'm not sure if this'll make it to the
old list now that I'm unsubscribed from it, but we'll see.)

Barrie Stott wrote:
> I didn't have /dev/lp0 and couldn't find a good way to get it. Now it
> comes by using `modprobe lp' and vanishes again with `rmmod lp'. And I
> can use udev info with /dev/lp0 now as well. Things are looking up.

:-)

One other thing you should probably know:  There's also a virtual "bus"
at /sys/devices/pnp0/ (and possibly pnp*) whose device directories
contain an "id" file.  This file contains the PNP ID of the device, and
can be used (with an appropriate udev rule, like the one in udev-117's
etc/udev/rules.d/80-drivers.rules file) to load modules automatically
from the PNP "bus".

I say this because the /sys/class/printer/lp0/ item's parent device is
on the PNP bus on my machine (it's /sys/devices/pnp0/00:06), and has an
ID of PNP0401 (for an ECP port, or PNP0400 for a non-ECP port).  The
parport_pc module also has a pair of modaliases (in recent kernels), of
pnp:dPNP0401 or pnp:dPNP0400.  So the pnp0/00:06 device will (with the
rule above) load the parport_pc module automatically.

(However, that still won't get you the lp module.  I think the only way
to get that is to either load it manually, or build it into the kernel.
I used to have a modprobe.conf rule to automatically load it, but I
deleted that when I started building it into the kernel.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHT0weS5vET1Wea5wRA2IdAKDSqtkI5rVsksy23wBRileMhOwdSgCfRnJo
tCKFNziijcAYWPb6ENvGA3M=Pmay
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Help wanted with parallel port rule

[Alexander E. Patrakov]

2007/11/30, Bryan Kadzban <bryan@kadzban.is-a-geek.net>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> (CC'ing the new list as well.  I'm not sure if this'll make it to the
> old list now that I'm unsubscribed from it, but we'll see.)
>
> Barrie Stott wrote:
> > I didn't have /dev/lp0 and couldn't find a good way to get it. Now it
> > comes by using `modprobe lp' and vanishes again with `rmmod lp'. And I
> > can use udev info with /dev/lp0 now as well. Things are looking up.
>
> :-)
>
> One other thing you should probably know:  There's also a virtual "bus"
> at /sys/devices/pnp0/ (and possibly pnp*) whose device directories
> contain an "id" file.  This file contains the PNP ID of the device, and
> can be used (with an appropriate udev rule, like the one in udev-117's
> etc/udev/rules.d/80-drivers.rules file) to load modules automatically
> from the PNP "bus".
>
> I say this because the /sys/class/printer/lp0/ item's parent device is
> on the PNP bus on my machine (it's /sys/devices/pnp0/00:06), and has an
> ID of PNP0401 (for an ECP port, or PNP0400 for a non-ECP port).  The
> parport_pc module also has a pair of modaliases (in recent kernels), of
> pnp:dPNP0401 or pnp:dPNP0400.  So the pnp0/00:06 device will (with the
> rule above) load the parport_pc module automatically.
>
> (However, that still won't get you the lp module.  I think the only way
> to get that is to either load it manually, or build it into the kernel.
> I used to have a modprobe.conf rule to automatically load it, but I
> deleted that when I started building it into the kernel.)

Indeed, a modprobe.conf line is what you need:

install parport /sbin/modprobe -i parport ; /sbin/modprobe lp ;
/sbin/modprobe ppdev ; :

Of course, it will work only if both parport and lp are modules.

-- 
Alexander E. Patrakov

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel