[PATCH] fix udevtrigger first/default/last ordering

[PATCH] fix udevtrigger first/default/last ordering

[Thomas de Grenier de Latour]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

Hi,

There is some logic in udevtrigger (udev-0.89 or current git) to make
some events being triggered first or last. But it doesn't work because,
in device_list_insert(), some "sysfs_path"-prefixed devices paths are
compared to some unprefixed paths (the ones from first_list/last_list).
The attached patch fixes that.

Thanks,

-- 
TGL.

[-- Attachment #2: udevtrigger-ordering.patch --]
[-- Type: text/x-patch, Size: 1048 bytes --]

diff --git a/udevtrigger.c b/udevtrigger.c
index bc8453a..49d6b9c 100644
--- a/udevtrigger.c
+++ b/udevtrigger.c
@@ -36,6 +36,7 @@
 static const char *udev_log_str;
 static int verbose;
 static int dry_run;
+static int sysfs_path_length;
 
 #ifdef USE_LOG
 void log_message(int priority, const char *format, ...)
@@ -77,13 +78,13 @@ static int device_list_insert(const char
 	int i;
 
 	for (i = 0; first_list[i] != NULL; i++) {
-		if (strncmp(path, first_list[i], strlen(first_list[i])) == 0) {
+		if (strncmp(path+sysfs_path_length, first_list[i], strlen(first_list[i])) == 0) {
 			device_list = &device_first_list;
 			break;
 		}
 	}
 	for (i = 0; last_list[i] != NULL; i++) {
-		if (strncmp(path, last_list[i], strlen(last_list[i])) == 0) {
+		if (strncmp(path+sysfs_path_length, last_list[i], strlen(last_list[i])) == 0) {
 			device_list = &device_last_list;
 			break;
 		}
@@ -341,6 +342,7 @@ int main(int argc, char *argv[], char *e
 	}
 
 	sysfs_init();
+	sysfs_path_length=strlen(sysfs_path);
 
 	udev_scan_bus();
 	udev_scan_class();

Re: [PATCH] fix udevtrigger first/default/last ordering

[Kay Sievers]

On Sat, Apr 08, 2006 at 05:51:57PM +0200, Thomas de Grenier de Latour wrote:
> There is some logic in udevtrigger (udev-0.89 or current git) to make
> some events being triggered first or last. But it doesn't work because,
> in device_list_insert(), some "sysfs_path"-prefixed devices paths are
> compared to some unprefixed paths

Fixed. Thanks a lot,
Kay


-------------------------------------------------------
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&kid\x110944&bid$1720&dat\x121642
_______________________________________________
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: [PATCH] fix udevtrigger first/default/last ordering

[juuso.alasuutari]

Quoting Kay Sievers <kay.sievers@vrfy.org>:

> On Sat, Apr 08, 2006 at 05:51:57PM +0200, Thomas de Grenier de Latour wrote:
> > There is some logic in udevtrigger (udev-0.89 or current git) to make
> > some events being triggered first or last. But it doesn't work because,
> > in device_list_insert(), some "sysfs_path"-prefixed devices paths are
> > compared to some unprefixed paths
>
> Fixed. Thanks a lot,
> Kay

I don't completely understand the issue that this patch deals with, but does it
have something to do with module loading order? This has been giving
considerable trouble for people (also previously discussed on this list), and
is still one major obstacle for udev to reliably replace hotplug. At least this
is the case for the distribution I assist in developing.

Is there a chance that udev could in the future load modules (network, audio,
etc.) in the same order every time if no significant hardware changes take
place? If yes, when and thanks to what changes? If not, what prevents it?

I apologise if this question has already been answered here. Feel free to point
me to a thread if necessary.

Juuso Alasuutari

----------------------------------------------------------------
This mail sent through L-secure: http://www.l-secure.net/



-------------------------------------------------------
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&kid\x110944&bid$1720&dat\x121642
_______________________________________________
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: [PATCH] fix udevtrigger first/default/last ordering

[Greg KH]

On Thu, Apr 13, 2006 at 02:22:49AM +0300, juuso.alasuutari@tamperelainen.org wrote:
> Quoting Kay Sievers <kay.sievers@vrfy.org>:
> 
> > On Sat, Apr 08, 2006 at 05:51:57PM +0200, Thomas de Grenier de Latour wrote:
> > > There is some logic in udevtrigger (udev-0.89 or current git) to make
> > > some events being triggered first or last. But it doesn't work because,
> > > in device_list_insert(), some "sysfs_path"-prefixed devices paths are
> > > compared to some unprefixed paths
> >
> > Fixed. Thanks a lot,
> > Kay
> 
> I don't completely understand the issue that this patch deals with, but does it
> have something to do with module loading order? This has been giving
> considerable trouble for people (also previously discussed on this list), and
> is still one major obstacle for udev to reliably replace hotplug. At least this
> is the case for the distribution I assist in developing.

It is?  What distro?

> Is there a chance that udev could in the future load modules (network, audio,
> etc.) in the same order every time if no significant hardware changes take
> place? If yes, when and thanks to what changes? If not, what prevents it?

No, as the modules could be loaded in any order if the buses are probed
a little bit differently next boot time.  Or if the BIOS reorders the
bus numbers.  Or another PCI device is added to the system.  Or one
removed.  Or any of a zillion different other things happening.

In short, any reliance on the order of modules being loaded, in order to
name devices properly for a system is broken.  Use persistant names,
that is what udev is for.  Look at /dev/disk/ for examples of how to do
this with block devices today.  It works wonderfully thanks to Kay's
work.

thanks,

greg k-h


-------------------------------------------------------
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&kid\x110944&bid$1720&dat\x121642
_______________________________________________
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