Skip to contentSkip to conversation

Why not picking up ENV variables?

DISCUSSION Moshe Yudkowsky 3 participants 7 messages Apr 2, 2006 – Apr 4, 2006

lore
Share & tools
lore

Moshe Yudkowsky

author
#0 lore raw

Here's the output of udevmonitor --env:

UDEV [1143983665.856252] add@/block/sdb
UDEV_LOG=3
ACTION­d
DEVPATH=/block/sdb
SUBSYSTEM=block
SEQNUM#89
MINOR
MAJOR=8 PHYSDEVPATH=/devices/pci0000:00/0000:00:10.3/usb4/4-4/4-4:1.0/host6/target6:0:0/6:0:0:0 PHYSDEVBUS=scsi
PHYSDEVDRIVER=sd
UDEVD_EVENT=1
ID_VENDOR=iriver
ID_MODEL=MassStorage_Disc
ID_REVISION01
ID_SERIAL=iriver_MassStorage_Disc
ID_TYPE=disk
ID_BUS=usb
ID_PATH=pci-0000:00:10.3-usb-0:4:1.0-scsi-0:0:0:0 DEVNAME=/dev/scsi/host6/bus0/target0/lun0/disc
DEVLINKS=/dev/sdb /dev/discs/disc2/disc /dev/disk/by-id/usb-iriver_MassStorage_Disc /dev/disk/by-path/pci-0000:00:10.3-usb-0:4:1.0-scsi-0:0:0:0

Now, I will tell you the truth: I have not yet been able to find any documentation that states, explicitly, what variables are part of SYSFS and what variables are part of ENV. I can figure out -- only by running udevinfo and reading the "sysfs" prefixes -- what info is SYSFS only.

However, when I read (e.g.) persistent.rules, I get the impression that some of the info that's in the udevmonitor --env printout isn't really part of the standard environment. Instead, it's imported there by path_id.

It'd be very nice to find documentation that explains what variables are part of ENV and which are not, by default.

In any case, here are two rules:

SUBSYSTEM="block", ACTION="add", ENV{ID_VENDOR}="iriver", ENV{ID_SERIAL}="iriver_MassStorage_Disc", SYMLINK+="iriver", RUN+="/etc/hotplug/usb/iriver"

SUBSYSTEM="block", ACTION="remove", ENV{ID_VENDOR}="iriver", ENV{ID_SERIAL}="iriver_MassStorage_Disc", RUN+="/etc/hotplug/usb/iriver"

Neither of these two rules will run. I've tried different variations, including SYMLINK= instead of SYMLINK+=, leaving off ID_VENDOR matching, etc.

If I use SYSFS variables, I can easily match that "add," but the goal is to also be able to match on "remove."

Now, what's interesting is that these very same variables are used by persistent.rules to create /dev/disk/by-*. So, for example, there's a device called /dev/disk/by-id/usb-iriver_MassStorage_Disc.

I will start some experiments with path_id and the order the files execute, but if someone wants to toss me a hint, it'll save me a lot of time.

Signature · 14 lines
  Moshe Yudkowsky
  work: http://www.Disaggregate.com
  book: http://www.PebbleAndAvalanche.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
author
#1 lore raw

In another test, I've modified the rules:

SUBSYSTEM="block" IMPORT{program}="path_id $devpath"

SUBSYSTEM="block", ACTION="add", ENV{ID_VENDOR}="iriver", ENV{ID_SERIAL}="iriver_MassStorage_Disc", SYMLINK+="iriver", RUN+="/etc/hotplug/usb/iriver", ENV{REMOVE_CMD}="/etc/hotplug/usb/iriver remove"

SUBSYSTEM="block", ACTION="remove", ENV{ID_VENDOR}="iriver", ENV{ID_SERIAL}="iriver_MassStorage_Disc", RUN+="/etc/hotplug/usb/iriver remove"

and I've also set them to run *after* the persistent.rules file. This should make certain that ID_VENDOR and ID_PATH are in the ENV -- even though I've certainly seen them in udevinfo printouts even without adding path_id myself.

While "add" works, the "remove" does not work. Furthermore, even thought run.rules executes, the ENV{REMOVE_CMD} that I've set does not run.

Help?

Signature · 14 lines
  Moshe Yudkowsky
  work: http://www.Disaggregate.com
  book: http://www.PebbleAndAvalanche.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
#2 lore raw
In reply to Moshe Yudkowsky

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 13 lines · Moshe Yudkowsky

In another test, I've modified the rules:

SUBSYSTEM="block" IMPORT{program}="path_id $devpath"

SUBSYSTEM="block", ACTION="add", ENV{ID_VENDOR}="iriver", ENV{ID_SERIAL}="iriver_MassStorage_Disc", SYMLINK+="iriver", RUN+="/etc/hotplug/usb/iriver", ENV{REMOVE_CMD}="/etc/hotplug/usb/iriver remove"

SUBSYSTEM="block", ACTION="remove", ENV{ID_VENDOR}="iriver", ENV{ID_SERIAL}="iriver_MassStorage_Disc", RUN+="/etc/hotplug/usb/iriver remove"

Quoted 6 lines

and I've also set them to run *after* the persistent.rules file. This should make certain that ID_VENDOR and ID_PATH are in the ENV -- even though I've certainly seen them in udevinfo printouts even without adding path_id myself.

While "add" works, the "remove" does not work.

Unless I misread the code, stored environment is not available when matching device event; it is imported after that, immediately before RUN programs are going to be run. As most other callouts are run only on ACTION="add", it means environment is mostly not available for remove rules.

Quoted 3 lines

Furthermore, even thought
run.rules executes, the ENV{REMOVE_CMD} that I've set does not run.

If I am right, it does not run for the same reason - ENV{REMOVE_CMD} is not defined when rule runs.

Quoted 1 line

Help?

Could you try if this patch helps?

udev_device.c +0 -0
index 5db2709..cd84a0a 100644

- --- a/udev_device.c
+++ b/udev_device.c
@@ -101,6 +101,7 @@ int udev_device_event(struct udev_rules

        if (major(udev->devt) != 0 && strcmp(udev->action, "remove") = 0) {
                struct name_entry *name_loop;
+               udev_db_get_device(udev, udev->dev->devpath);
                udev_rules_get_run(rules, udev);
                if (udev->ignore_device) {
                        info("device event will be ignored");

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEMAAqR6LMutpd94wRAk1QAJ9MmBhGr/P5JS9uFjN+zZhLKFWhYwCgvXBq YRwPF2XwwnItbtgSYRE3P68=DzuD
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#3 lore raw
In reply to Moshe Yudkowsky
Quoted 4 lines

Unless I misread the code, stored environment is not available when matching device event; it is imported after that, immediately before RUN programs are going to be run. As most other callouts are run only on ACTION="add", it means environment is mostly not available for remove rules.

I will certainly try to find time to run against this patch. Is there a "best practices" method for "remove" events? If sysfs isn't available, and I can't import to the environment via path_id, then what's left to match against?

Signature · 14 lines
Moshe Yudkowsky * [email protected] * www.pobox.com/~moshe
  "The odds are good, but the goods are odd."
    	     -- Alaskan women, on the high ratio of men to women in Alaska


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
author
#4 lore raw
In reply to Moshe Yudkowsky

This patch didn't seem to help.

Quoted 7 lines

Could you try if this patch helps?

udev_device.c +1 -1
index 5db2709..cd84a0a 100644
- --- a/udev_device.c
+++ b/udev_device.c

udev_device.c int udev_device_event(struct udev_rules

Quoted 9 lines
udev_device.c +1 -1
@@ -101,6 +101,7 @@ int udev_device_event(struct udev_rules
        if (major(udev->devt) != 0 && strcmp(udev->action, "remove") = 0) {
                struct name_entry *name_loop;
 
+               udev_db_get_device(udev, udev->dev->devpath);
                udev_rules_get_run(rules, udev);
                if (udev->ignore_device) {
                        info("device event will be ignored");
 
- -andrey

(1) The relevant lines in udev_device.c now read:

	if (major(udev->devt) != 0 && strcmp(udev->action, "remove") = 0) {
		struct name_entry *name_loop;

		udev_db_get_device(udev, udev->dev->devpath);
		udev_rules_get_run(rules, udev);
		if (udev->ignore_device) {
			info("device event will be ignored");
			return 0;
		}

and then I simply ran:

make
make install

in my normal environment. I didn't make or install, e.g., ata-id.

(2) On unplug, the output of udevmonitor --env reads:

Quoted 13 lines

UDEV [1144149290.702789] remove@/block/sdb
UDEV_LOG=3
ACTION=remove
DEVPATH=/block/sdb
SUBSYSTEM=block
SEQNUM374
MINOR
MAJOR=8
PHYSDEVPATH=/devices/pci0000:00/0000:00:10.3/usb4/4-4/4-4:1.0/host21/target21:0:0/21:0:0:0
PHYSDEVBUS=scsi
PHYSDEVDRIVER=sd
UDEVD_EVENT=1
DEVLINKS=/dev/sdb /dev/discs/disc2/disc /dev/disk/by-id/usb-iriver_MassStorage_Disc /dev/disk/by-path/pci-0000:00:10.3-usb-0:4:1.0-scsi-0:0:0:0 /dev/iriverDEVNAME=/dev/scsi/host21/bus0/target0/lun0/disc

Quoted 8 lines

ID_VENDOR=iriver
ID_MODEL=MassStorage_Disc
ID_REVISION01
ID_SERIAL=iriver_MassStorage_Disc
ID_TYPE=disk
ID_BUS=usb
ID_PATH=pci-0000:00:10.3-usb-0:4:1.0-scsi-0:0:0:0
REMOVE_CMD=/etc/hotplug/usb/iriver remove

(3) the rules are (the "add" rule works, the "remove" does not):

SUBSYSTEM="block" IMPORT{program}="path_id $devpath"

SUBSYSTEM="block", ACTION="add", ENV{ID_VENDOR}="iriver", ENV{ID_SERIAL}="iriver_MassStorage_Disc", SYMLINK+="iriver", RUN+="/etc/hotplug/usb/iriver", ENV{REMOVE_CMD}="/etc/hotplug/usb/iriver remove"

SUBSYSTEM="block", ACTION="remove", ENV{ID_VENDOR}="iriver", ENV{ID_SERIAL}="iriver_MassStorage_Disc", RUN+="/etc/hotplug/usb/iriver"

Please let me know what further tests to run.

Signature · 14 lines
  Moshe Yudkowsky
  work: http://www.Disaggregate.com
  book: http://www.PebbleAndAvalanche.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
#5 lore raw
In reply to Moshe Yudkowsky

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 4 lines · Moshe Yudkowsky

This patch didn't seem to help.

Quoted 2 lines

Could you try if this patch helps?

right; the patch below does (verified with exact copy of your rule).

- -andrey

udev_device.c +0 -0
index 5db2709..6ee6b13 100644

- --- a/udev_device.c
+++ b/udev_device.c
@@ -101,6 +101,10 @@ int udev_device_event(struct udev_rules

        if (major(udev->devt) != 0 && strcmp(udev->action, "remove") = 0) {
                struct name_entry *name_loop;
+               udev_db_get_device(udev, udev->dev->devpath);
+               /* restore stored persistent data */
+               list_for_each_entry(name_loop, &udev->env_list, node)
+                       putenv(name_loop->name);
                udev_rules_get_run(rules, udev);
                if (udev->ignore_device) {
                        info("device event will be ignored");
@@ -109,9 +113,6 @@ int udev_device_event(struct udev_rules
                /* get data from db, remove db-entry, delete node */
                retval = udev_remove_device(udev);

- - /* restore stored persistent data */
- - list_for_each_entry(name_loop, &udev->env_list, node)

- -                       putenv(name_loop->name);
                return retval;
        }

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEMp9dR6LMutpd94wRAoxiAKCzzMd5UqT5JxMFGK2mEx+Kp8JhZwCcDO6g 1kIiyFxtXo/ShqzoC5NCWVc=UctB
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#6 lore raw
In reply to Moshe Yudkowsky
Quoted 2 lines

right; the patch below does (verified with exact copy of your rule).

Andrey,

Thank you. This patch works. I tested it with udev-089 (which, I finally realized, was the not the package you were working with).

I see not only the "remove" I expect from the rule, but also the REMOVE_CMD event I created in the ENV{REMOVE_CMD}. This is excellent, because it means that I can actually control devices on remove.

Thank you very much for your help.

Signature · 13 lines
Moshe Yudkowsky * [email protected] * www.pobox.com/~moshe
  "You may fire when ready, Gridley." -- Commodore George Dewey


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel