udev - advanced user query options

This patch improves the user options for udev.
It is possible now to query for the name, the symlinks or owner/group. If asked for the name of the node we are able to prepend the udev_root with the -r option.

SAMPLE:

  kay@pim:~/src/udev.test$ ./udev -V
  udev, version 012_bk

  kay@pim:~/src/udev.test$ ./udev -h
  Usage: [-qrVh]
    -q <name>  query database for the specified value
    -p <path>  device path used for query
    -r         print udev root
    -V         print udev version
    -h         print this help text

  kay@pim:~/src/udev.test$ ./udev -r
  /udev/

  kay@pim:~/src/udev.test$ ./udev -q name -p /class/video4linux/video0
  video/webcam0

  kay@pim:~/src/udev.test$ ./udev -q symlink -p /class/video4linux/video0
  camera0 kamera0

  kay@pim:~/src/udev.test$ ./udev -q owner -p /class/video4linux/video0
  501

  kay@pim:~/src/udev.test$ ./udev -r -q name -p /class/video4linux/video0
  /udev/video/webcam0

thanks,
Kay

diff -Nru a/udev.c b/udev.c
@@ -82,13 +82,26 @@
 	return seqnum;
 }
 
+enum query_type {
+	NONE,
+	NAME,
+	SYMLINK,
+	OWNER,
+	GROUP
+};
+
 static inline int udev_user(int argc, char **argv)
 {
-	static const char short_options[] = "q:rVh";
+	static const char short_options[] = "p:q:rVh";
 	int option;
 	int retval = -EINVAL;
 	struct udevice dev;
+	int root = 0;
+	enum query_type query = NONE;
+	char result[NAME_SIZE] = "";
+	char path[NAME_SIZE] = "";
 
+	/* get command line options */
 	while (1) {
 		option = getopt(argc, argv, short_options);
 		if (option == -1)

@@ -96,25 +109,40 @@
 
 		dbg("option '%c'", option);
 		switch (option) {
+		case 'p':
+			dbg("udev path: %s\n", optarg);
+			strfieldcpy(path, optarg);
+			break;
+
 		case 'q':
 			dbg("udev query: %s\n", optarg);
-			retval = udevdb_open_ro();
-			if (retval != 0) {
-				printf("unable to open udev database\n");
-				return -1;
+
+			if (strcmp(optarg, "name") == 0) {
+				query = NAME;
+				break;
+			}
+
+			if (strcmp(optarg, "symlink") == 0) {
+				query = SYMLINK;
+				break;
 			}
-			retval = udevdb_get_dev(optarg, &dev);
-			if (retval == 0) {
-				printf("%s\n", dev.name);
-			} else {
-				printf("device not found in udev database\n");
+
+			if (strcmp(optarg, "owner") == 0) {
+				query = OWNER;
+				break;
+			}
+
+			if (strcmp(optarg, "group") == 0) {
+				query = GROUP;
+				break;
 			}
-			udevdb_exit();
-			return retval;
+
+			printf("unknown query type\n");
+			return -EINVAL;
 
 		case 'r':
-			printf("%s\n", udev_root);
-			return 0;
+			root = 1;
+			break;
 
 		case 'V':
 			printf("udev, version %s\n", UDEV_VERSION);

@@ -128,14 +156,63 @@
 		}
 	}
 
+	/* process options */
+	if (query != NONE) {
+		if (path[0] == '\0') {
+			printf("query needs device path specified\n");
+			return -EINVAL;
+		}
+
+		retval = udevdb_open_ro();
+		if (retval != 0) {
+			printf("unable to open udev database\n");
+			return -EACCES;
+		}
+		retval = udevdb_get_dev(path, &dev);
+		if (retval == 0) {
+			switch(query) {
+			case NAME:
+				if (root)
+				strfieldcpy(result, udev_root);
+				strncat(result, dev.name, sizeof(result));
+				break;
+
+			case SYMLINK:
+				strfieldcpy(result, dev.symlink);
+				break;
+
+			case GROUP:
+				strfieldcpy(result, dev.group);
+				break;
+
+			case OWNER:
+				strfieldcpy(result, dev.owner);
+				break;
+
+			default:
+				break;
+			}
+			printf("%s\n", result);
+		} else {
+			printf("device not found in udev database\n");
+		}
+		udevdb_exit();
+		return retval;
+	}
+
+	if (root) {
+		printf("%s\n", udev_root);
+		return 0;
+	}
+
 help:
 	printf("Usage: [-qrVh]\n"
-	       "  -q <path>  query database for the name of the created node\n"
+	       "  -q <name>  query database for the specified value\n"
+	       "  -p <path>  device path used for query\n"
 	       "  -r         print udev root\n"
 	       "  -V         print udev version\n"
 	       "  -h         print this help text\n"
 	       "\n");
-
 	return retval;
 }
 

Dude, this is some really great work - keep it up!

Stuff like this can be really useful for scripts or debugging.

Robert Love

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Hey, thanks. I enjoy it.
Nice to see somebody finding it useful too.

Kay

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

This is quite neat, but is it backwards compatible with how the current udev release works? I actually do stuff like

udev -q /block/sda

from HAL and expect to get the reply

sda

Of course, if and when udev becomes a daemon I would probably use a d-bus method anyway.

Thanks,
David

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Very nice, applied, thanks.

Hm, care to update the man page with this information, and the '-h' option to explain queries a bit more?

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Nope, this is now changed, sorry :(

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Yes, I'll take the man page in the next two hours.

Here is the '-h' and a '-d' to dump the whole database:

  kay@pim:~/src/udev.kay$ ./udev -d
  P: /block/hdb/hdb1
  N: hdb1
  S: 
  O: 
  G: 

P: /class/video4linux/video0
N: video/webcam0
S: camera0 kamera0
O: 500
G: 500

P: /block/hdc
N: hdc
S:
O:
G:

thanks,
Kay

diff -Nru a/udev.c b/udev.c
@@ -82,6 +82,16 @@
 	return seqnum;
 }
 
+static void print_record(char *path, struct udevice *dev)
+{
+	printf("P: %s\n", path);
+	printf("N: %s\n", dev->name);
+	printf("S: %s\n", dev->symlink);
+	printf("O: %s\n", dev->owner);
+	printf("G: %s\n", dev->group);
+	printf("\n");
+}
+
 enum query_type {
 	NONE,
 	NAME,

@@ -92,7 +102,7 @@
 
 static inline int udev_user(int argc, char **argv)
 {
-	static const char short_options[] = "p:q:rVh";
+	static const char short_options[] = "dp:q:rVh";
 	int option;
 	int retval = -EINVAL;
 	struct udevice dev;

@@ -144,6 +154,16 @@
 			root = 1;
 			break;
 
+		case 'd':
+			retval = udevdb_open_ro();
+			if (retval != 0) {
+				printf("unable to open udev database\n");
+				return -EACCES;
+			}
+			retval = udevdb_dump(print_record);
+			udevdb_exit();
+			return retval;
+
 		case 'V':
 			printf("udev, version %s\n", UDEV_VERSION);
 			return 0;

@@ -206,12 +226,17 @@
 	}
 
 help:
-	printf("Usage: [-qrVh]\n"
-	       "  -q <name>  query database for the specified value\n"
-	       "  -p <path>  device path used for query\n"
-	       "  -r         print udev root\n"
-	       "  -V         print udev version\n"
-	       "  -h         print this help text\n"
+	printf("Usage: [-pqrdVh]\n"
+	       "  -q TYPE  query database for the specified value:\n"
+	       "             'name'    name of device node\n"
+	       "             'symlink' pointing to node\n"
+	       "             'owner'   of node\n"
+	       "             'group'   of node\n"
+	       "  -p PATH  sysfs device path used for query\n"
+	       "  -r       print udev root\n"
+	       "  -d       dump whole database\n"
+	       "  -V       print udev version\n"
+	       "  -h       print this help text\n"
 	       "\n");
 	return retval;
 }

diff -Nru a/udevdb.c b/udevdb.c
@@ -124,7 +124,7 @@
 			dbg("unable to initialize in-memory database");
 		else
 			dbg("unable to initialize database at '%s'", udev_db_filename);
-		return -EINVAL;
+		return -EACCES;
 	}
 	return 0;
 }

@@ -137,7 +137,30 @@
 	udevdb = tdb_open(udev_db_filename, 0, 0, O_RDONLY, 0);
 	if (udevdb == NULL) {
 		dbg("unable to open database at '%s'", udev_db_filename);
+		return -EACCES;
+	}
+	return 0;
+}
+
+void (*user_record_callback) (char *path, struct udevice *dev);
+
+static int traverse_callback(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA dbuf, void *state)
+{
+	user_record_callback((char*) key.dptr, (struct udevice*) dbuf.dptr);
+	return 0;
+}
+
+/**
+ * udevdb_dump: dumps whole database by passing record data to user function
+ * @user_record_handler: user function called for every record in the database
+ */
+int udevdb_dump(void (*user_record_handler) (char *path, struct udevice *dev))
+{
+	if (user_record_handler == NULL) {
+		dbg("invalid user record handling function");
 		return -EINVAL;
 	}
+	user_record_callback = user_record_handler;
+	tdb_traverse(udevdb, traverse_callback, NULL);
 	return 0;
 }

diff -Nru a/udevdb.h b/udevdb.h
@@ -12,6 +12,7 @@
 extern void udevdb_exit(void);
 extern int udevdb_init(int init_flag);
 extern int udevdb_open_ro(void);
+extern int udevdb_dump(void (*user_record_handler) (char *path, struct udevice *dev));
 
 extern int udevdb_add_dev(const char *path, const struct udevice *dev);
 extern int udevdb_get_dev(const char *path, struct udevice *dev);

Great.

Very nice, applied. But I did have to make one small change to get the code to build properly with klibc:

Ready for takeoff!
Here is the man page update after my udev-weekend :)

Kay

===== udev.8 1.29 vs edited =====

@@ -5,7 +5,7 @@
 .BI udev " hotplug-subsystem"
 .br
 .B udev
-.RI "[-q " sysfs_path "] [-rVh]"
+.RI "[-q " query_type " -p " sysfs_path "] [-drVh]"
 .SH "DESCRIPTION"
 .B udev
 creates or removes device node files usually located in the /dev directory.

@@ -21,14 +21,14 @@
 .B udev
 reads the sysfs directory of the given device to collect device attributes
 like label, serial number or bus device number.
-These attributes are treated as a key
-to determine a unique name for device file creation.
+These attributes may used as keys to determine a
+unique name for device file creation.
 .B udev
 maintains a database for devices present on the system.
 .br
 On device removal,
 .B udev
-queries the internal database for the name of the device file to be deleted.
+queries its database for the name of the device file to be deleted.
 .SH "OPTIONS"
 .B udev
 normally is called by

@@ -42,11 +42,21 @@
 .TP
 .B -r
 Print the the
-.B udev
-root directory.
+.B udev_root
+directory. When used in conjunction with a query for the node name, the
+.B udev_root
+will be prepended.
+.TP
+.BI -q " query_type"
+Query the database for specified value of a created device node.
+Valid types are:
+.BR name ", " symlink ", " owner " or " group .
 .TP
-.BI -q " sysfs_path"
-Query with the sysfs path as argument for the name of the created device node.
+.BI -p " sysfs_path"
+Specify the sysfs path needed for the query.
+.TP
+.B -q
+Dump the whole database.
 .TP
 .B -h
 Print help text.

@@ -115,61 +125,50 @@
 .I /etc/udev/udev.conf
 file.
 .P
-Every line in the rules file define the mapping between device attributes and
-the device file name. It starts with a keyword defining the method used to
-match, followed by one ore more keys to compare and the filename for the
-device. One ore more optional symlinks targeting the node may be specified.
+Every line in the rules file defines the mapping between device attributes
+and the device file name. One ore more keys are specified to match a rule
+with the current device. If all keys are matching, the rule will be applied
+and the name is used for the device node. One or more optional symlinks
+targeting the node may be specified.
 .br
-If no matching configuration is found, the default kernel device name
-is used.
+If no matching rule is found, the default kernel device name is used.
 .P
 The line format is:
 .sp
-.I method, key,[key,...] name [, symlink]
+.I key,[key,...] name [, symlink]
 .sp
-where valid methods with corresponding keys are:
+where keys are:
 .TP
-.B CALLOUT
-calling external program, that returns a string to match.  The
 .B BUS
-key is optional, but if specified, the sysfs device bus must be able to be
-determined by a "device" symlink.
-.br
-.RB "keys: " BUS ", " PROGRAM ", " ID
+Match the bus type of the device.
+(The sysfs device bus must be able to be determined by a "device" symlink.)
 .TP
-.B LABEL
-device label or serial number, like USB serial number, SCSI UUID or
-file system label.  Up to 5 different sysfs files can be checked, with
-all of the values being required in order to match the rule.  The
-.B BUS
-key is optional, but if specified, the sysfs device bus must be able to be
-detemined by a "device" symlink.
-.br
-.RB "keys: " BUS ", " SYSFS_
+.B KERNEL
+Match the kernel device name.
 .TP
-.B NUMBER
-device number on the bus, like PCI bus id
-.br
-.RB "keys: " BUS ", " ID
-.TP
-.B TOPOLOGY
-device position on bus, like physical port of USB device
-.br
-.RB "keys: " BUS ", " PLACE
+.B ID
+Match the device number on the bus, like PCI bus id.
 .TP
-.B REPLACE
-string replacement of the kernel device name
-.br
-.RB "key: " KERNEL
-.TP
-.B IGNORE
-tell udev to not care about creation of this device, e.g. because the
-device is already handled by another program
-.br
-.RB "key: " KERNEL
-.P
-The methods are applied in the following order:
-.BR IGNORE ", " CALLOUT ", " LABEL ", " NUMBER ", " TOPOLOGY ", " REPLACE "."
+.B PLACE
+Match the topological position on bus, like physical port of USB device
+.TP
+.BI SYSFS_ filename
+Match sysfs device attribute like label, vendor, USB serial number, SCSI UUID
+or file system label.  Up to 5 different sysfs files can be checked, with
+all of the values being required in order to match the rule.
+.TP
+.B PROGRAM
+Call external program. This key is valid if the program returns successful.
+The string returned by the program may additionally matched with the
+.B RESULT
+key.
+.TP
+.B RESULT
+Match the returned string of the last
+.B PROGRAM
+call. This key may used in any following rule after a
+.B PROGRAM
+call.
 .P
 .RB "The " NAME " ," SYMLINK " and " PROGRAM
 fields support simple printf-like string substitution:

@@ -203,25 +202,25 @@
 .sp
 .nf
 # if /sbin/scsi_id returns "OEM 0815" device will be called disk1
-CALLOUT, BUS="scsi", PROGRAM="/sbin/scsi_id", ID="OEM 0815", NAME="disk1"
+BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="OEM 0815", NAME="disk1"
 
 # USB printer to be called lp_color
-LABEL, BUS="usb", SYSFS_serial="W09090207101241330", NAME="lp_color"
+BUS="usb", SYSFS_serial="W09090207101241330", NAME="lp_color"
 
 # SCSI disk with a specific vendor and model number is to be called boot
-LABEL, BUS="scsi", SYSFS_vendor="IBM", SYSFS_model="ST336", NAME="boot%n"
+BUS="scsi", SYSFS_vendor="IBM", SYSFS_model="ST336", NAME="boot%n"
 
 # sound card with PCI bus id 00:0b.0 to be called dsp
-NUMBER, BUS="pci", ID="00:0b.0", NAME="dsp"
+BUS="pci", ID="00:0b.0", NAME="dsp"
 
 # USB mouse at third port of the second hub to be called mouse1
-TOPOLOGY, BUS="usb", PLACE="2.3", NAME="mouse1"
+BUS="usb", PLACE="2.3", NAME="mouse1"
 
 # ttyUSB1 should always be called pda with two additional symlinks
-REPLACE, KERNEL="ttyUSB1", NAME="pda", SYMLINK="palmtop handheld"
+KERNEL="ttyUSB1", NAME="pda", SYMLINK="palmtop handheld"
 
 # multiple USB webcams with symlinks to be called webcam0, webcam1, ...
-LABEL, BUS="usb", SYSFS_model="XV3", NAME="video%n", SYMLINK="webcam%n"
+BUS="usb", SYSFS_model="XV3", NAME="video%n", SYMLINK="webcam%n"
 .fi
 .P
 Permissions and ownership for the created device files may specified at

Just for information. This seems to fix the gcc with klibc :)

@@ -133,7 +133,7 @@
        LIBC =  $(ARCH_LIB_OBJS) $(LIB_OBJS) $(CRT0)
        CFLAGS += -nostdinc -I$(INCLUDE_DIR) -I$(KLIBC_DIR)/arch/$(ARCH)/include \
                -I$(INCLUDE_DIR)/bits$(BITSIZE) -I$(GCCINCDIR) -I$(LINUX_INCLUDE_DIR) \
-               -D__KLIBC__
+               -D__KLIBC__ -fno-builtin-printf
        LIB_OBJS         LDFLAGS = --static --nostdlib -nostartfiles -nodefaultlibs
 else
 

thanks,
Kay

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Applied, thanks.

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Thanks, I've reverted my change and applied this patch.

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

What about reverse lookup?

pear:~ # udev -q name /dev/test/blah-8745
query needs device path specified
pear:~ # udev -q /dev/test/blah-8745
unknown query type
pear:~ # udev -r -q name -p /block/sda
/dev/test/blah-8745

options starting with / should mean it is an absolute path, stuff without / should assume relative path names.

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Yeah, that's a bit harder right now, sorry.
We can either add another table to the database (like the original database code was structured), or iterate over all devices in the database.

Either way, it would be nice to have. Anyone want to write a patch? :)

thanks,

greg k-h

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Iteration is very, very easy with my dump callback. I was expecting something like this :)

Is there any plus value to have a second index?
Otherwise I will do it with the dump logic.

Kay

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

It's a speed vs. database size trade off. I think we can handle the speed hit :)

That sounds like a reasonable way to do it.

thanks,

gre k-h

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

If it adds too much code, make it an external tool. I think there is not much point to add all and everything to the udev binary. Maybe something like kinit, which links libipconfig.a and libnfsmount.a.

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

It's already done. Patch is on the list.
It needs only a few lines more than the dump code :)

Kay

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I agree. I envision that when udev splits up into a daemon and sending program, it will also spin off a "query the database" program to handle this.

thanks,

greg k-h

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

udev? daemon? huh?

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

udev will be split into a daemon one of these days. It's needed to make sure we act apon hotplug events in the proper order.

thanks,

greg k-h

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

How does a daemon help in that situation?

event foo
SEQNUM=1 ACTION�d
SEQNUM=2 ACTION=remove
SEQNUM=3 ACTION�d

How will you make sure that #2 is processed before #3, even if #3 arrives earlier? And why would it matter for mknod?
I bet that a simple record '#3 add' in the database will make sure that #2 is handled as bogus event.

USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

We can reorder events to their proper order.

Sleep until we see #2. The devices could be different or we don't want to add and then remove a node that we should have removed and then added.

But we got #2 after #3, right? We already added the node. Now we remove it? What if it was pointing to a different device?

Anyway, a small daemon should work nicely to handle stuff like this.

thanks,

greg k-h

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel