Skip to contentSkip to conversation

coldplug - emit hotplug events from sysfs

RFC In review Kay Sievers 7 participants 17 messages Oct 1, 2005 – Oct 29, 2005

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

RFC 1/1 coldplug - emit hotplug events from sysfs

Here is another approach to address the coldplug problem. After playing around with "udevsythesize" it felt stupid to try to compose all the events from sysfs values which will never be exactly the same as the kernel event.
This patch adds a "uevent" file to all class/block/bus-devices. Writing to this file, will just emit the hotplug event from the kernel again. udevstart and all the coldplug logic can be 3 lines of shell-script now. Boots fine and is _very_ fast on my box.

What do you think?

Thanks,
Kay

------------
From: Kay Sievers <[email protected]>
Subject: add sysfs attr to re-emit device hotplug event

A "coldplug + udevstart" can be simple like this:
for i in /sys/block/*/*/uevent; do echo 1 > $i; done for i in /sys/class/*/*/uevent; do echo 1 > $i; done for i in /sys/bus/*/devices/*/uevent; do echo 1 > $i; done

---

drivers/base/class.c +14 -2
@@ -442,6 +442,13 @@ static ssize_t show_dev(struct class_dev
 	return print_dev_t(buf, class_dev->devt);
 }
 
+static ssize_t store_uevent(struct class_device *class_dev,
+			    const char *buf, size_t count)
+{
+	kobject_hotplug(&class_dev->kobj, KOBJ_ADD);
+	return count;
+}
+
 void class_device_initialize(struct class_device *class_dev)
 {
 	kobj_set_kset_s(class_dev, class_obj_subsys);
@@ -497,6 +504,12 @@ int class_device_add(struct class_device
 		goto register_done;
 
 	/* add the needed attributes to this device */
+	class_dev->uevent_attr.attr.name = "uevent";
+	class_dev->uevent_attr.attr.mode = S_IWUSR;
+	class_dev->uevent_attr.attr.owner = parent->owner;
+	class_dev->uevent_attr.store = store_uevent;
+	class_device_create_file(class_dev, &class_dev->uevent_attr);
+
 	if (MAJOR(class_dev->devt)) {
 		struct class_device_attribute *attr;
 		attr = kzalloc(sizeof(*attr), GFP_KERNEL);
@@ -505,12 +518,10 @@ int class_device_add(struct class_device
 			kobject_del(&class_dev->kobj);
 			goto register_done;
 		}
-
 		attr->attr.name = "dev";
 		attr->attr.mode = S_IRUGO;
 		attr->attr.owner = parent->owner;
 		attr->show = show_dev;
-		attr->store = NULL;
 		class_device_create_file(class_dev, attr);
 		class_dev->devt_attr = attr;
 	}
@@ -620,6 +631,7 @@ void class_device_del(struct class_devic
 		sysfs_remove_link(&class_dev->kobj, "device");
 		sysfs_remove_link(&class_dev->dev->kobj, class_name);
 	}
+	class_device_remove_file(class_dev, &class_dev->uevent_attr);
 	if (class_dev->devt_attr)
 		class_device_remove_file(class_dev, class_dev->devt_attr);
 	class_device_remove_attrs(class_dev);
drivers/base/core.c +16 -0
@@ -154,6 +154,13 @@ static struct kset_hotplug_ops device_ho
 	.hotplug =	dev_hotplug,
 };
 
+static ssize_t store_uevent(struct device *dev, struct device_attribute *attr,
+			    const char *buf, size_t count)
+{
+	kobject_hotplug(&dev->kobj, KOBJ_ADD);
+	return count;
+}
+
 /**
  *	device_subsys - structure to be registered with kobject core.
  */
@@ -258,6 +265,14 @@ int device_add(struct device *dev)
 
 	if ((error = kobject_add(&dev->kobj)))
 		goto Error;
+
+	dev->uevent_attr.attr.name = "uevent";
+	dev->uevent_attr.attr.mode = S_IWUSR;
+	if (dev->driver)
+		dev->uevent_attr.attr.owner = dev->driver->owner;
+	dev->uevent_attr.store = store_uevent;
+	device_create_file(dev, &dev->uevent_attr);
+
 	kobject_hotplug(&dev->kobj, KOBJ_ADD);
 	if ((error = device_pm_add(dev)))
 		goto PMError;
@@ -349,6 +364,7 @@ void device_del(struct device * dev)
 
 	if (parent)
 		klist_del(&dev->knode_parent);
+	device_remove_file(dev, &dev->uevent_attr);
 
 	/* Notify the platform of the removal, in case they
 	 * need to do anything...
drivers/block/genhd.c +24 -0
@@ -337,10 +337,30 @@ static ssize_t disk_attr_show(struct kob
 	return ret;
 }
 
+static ssize_t disk_attr_store(struct kobject * kobj, struct attribute * attr,
+			       const char *page, size_t count)
+{
+	struct gendisk *disk = to_disk(kobj);
+	struct disk_attribute *disk_attr +		container_of(attr,struct disk_attribute,attr);
+	ssize_t ret = 0;
+
+	if (disk_attr->store)
+		ret = disk_attr->store(disk, page, count);
+	return ret;
+}
+
 static struct sysfs_ops disk_sysfs_ops = {
 	.show	= &disk_attr_show,
+	.store	= &disk_attr_store,
 };
 
+static ssize_t disk_uevent_store(struct gendisk * disk,
+				 const char *buf, size_t count)
+{
+	kobject_hotplug(&disk->kobj, KOBJ_ADD);
+	return count;
+}
 static ssize_t disk_dev_read(struct gendisk * disk, char *page)
 {
 	dev_t base = MKDEV(disk->major, disk->first_minor); 
@@ -382,6 +402,10 @@ static ssize_t disk_stats_read(struct ge
 		jiffies_to_msecs(disk_stat_read(disk, io_ticks)),
 		jiffies_to_msecs(disk_stat_read(disk, time_in_queue)));
 }
+static struct disk_attribute disk_attr_uevent = {
+	.attr = {.name = "uevent", .mode = S_IWUSR },
+	.store	= disk_uevent_store
+};
 static struct disk_attribute disk_attr_dev = {
 	.attr = {.name = "dev", .mode = S_IRUGO },
 	.show	= disk_dev_read
@@ -404,6 +428,7 @@ static struct disk_attribute disk_attr_s
 };
 
 static struct attribute * default_attrs[] = {
+	&disk_attr_uevent.attr,
 	&disk_attr_dev.attr,
 	&disk_attr_range.attr,
 	&disk_attr_removable.attr,
fs/partitions/check.c +26 -1
@@ -192,6 +192,7 @@ check_partition(struct gendisk *hd, stru
 struct part_attribute {
 	struct attribute attr;
 	ssize_t (*show)(struct hd_struct *,char *);
+	ssize_t (*store)(struct hd_struct *,const char *, size_t);
 };
 
 static ssize_t 
@@ -201,14 +202,33 @@ part_attr_show(struct kobject * kobj, st
 	struct part_attribute * part_attr = container_of(attr,struct part_attribute,attr);
 	ssize_t ret = 0;
 	if (part_attr->show)
-		ret = part_attr->show(p,page);
+		ret = part_attr->show(p, page);
+	return ret;
+}
+static ssize_t
+part_attr_store(struct kobject * kobj, struct attribute * attr,
+		const char *page, size_t count)
+{
+	struct hd_struct * p = container_of(kobj,struct hd_struct,kobj);
+	struct part_attribute * part_attr = container_of(attr,struct part_attribute,attr);
+	ssize_t ret = 0;
+
+	if (part_attr->store)
+		ret = part_attr->store(p, page, count);
 	return ret;
 }
 
 static struct sysfs_ops part_sysfs_ops = {
 	.show	=	part_attr_show,
+	.store	=	part_attr_store,
 };
 
+static ssize_t part_uevent_store(struct hd_struct * p,
+				 const char *page, size_t count)
+{
+	kobject_hotplug(&p->kobj, KOBJ_ADD);
+	return count;
+}
 static ssize_t part_dev_read(struct hd_struct * p, char *page)
 {
 	struct gendisk *disk = container_of(p->kobj.parent,struct gendisk,kobj);
@@ -229,6 +249,10 @@ static ssize_t part_stat_read(struct hd_
 		       p->reads, (unsigned long long)p->read_sectors,
 		       p->writes, (unsigned long long)p->write_sectors);
 }
+static struct part_attribute part_attr_uevent = {
+	.attr = {.name = "uevent", .mode = S_IWUSR },
+	.store	= part_uevent_store
+};
 static struct part_attribute part_attr_dev = {
 	.attr = {.name = "dev", .mode = S_IRUGO },
 	.show	= part_dev_read
@@ -247,6 +271,7 @@ static struct part_attribute part_attr_s
 };
 
 static struct attribute * default_attrs[] = {
+	&part_attr_uevent.attr,
 	&part_attr_dev.attr,
 	&part_attr_start.attr,
 	&part_attr_size.attr,
include/linux/device.h +28 -29

93 lines not on this page · raw message

include/linux/genhd.h +1 -0
@@ -132,6 +132,7 @@ struct gendisk {
 struct disk_attribute {
 	struct attribute attr;
 	ssize_t (*show)(struct gendisk *, char *);
+	ssize_t (*store)(struct gendisk *, const char *, size_t);
 };
 
 /* 

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#1 lore raw
Quoted 7 lines · Kay Sievers

This patch adds a "uevent" file to all class/block/bus-devices. Writing to this file, will just emit the hotplug event from the kernel again. udevstart and all the coldplug logic can be 3 lines of shell-script now. Boots fine and is _very_ fast on my box.

What do you think?

Cute :) Seems like a much more efficient way of doing it, just use the kernel's own code again.

Scott

Signature · 2 lines
Scott James Remnant
[email protected]
#2 lore raw
In reply to Kay Sievers
Quoted 10 lines · Kay Sievers

Here is another approach to address the coldplug problem. After playing around with "udevsythesize" it felt stupid to try to compose all the events from sysfs values which will never be exactly the same as the kernel event.
This patch adds a "uevent" file to all class/block/bus-devices. Writing to this file, will just emit the hotplug event from the kernel again. udevstart and all the coldplug logic can be 3 lines of shell-script now. Boots fine and is _very_ fast on my box.

What do you think?

It looks really nice, but will we still be able to differientate coldplug events in udev rules?
For example, in Mandriva, we do PCI coldplug for USB controllers only, because we handle other stuff (sound, network, ...) later in services. We used to rely on UDEV_START in udev rules.

Signature · 13 lines
Olivier Blin
Mandriva



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
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 Kay Sievers
Quoted 11 lines · Olivier Blin
Quoted 9 lines · Kay Sievers

Here is another approach to address the coldplug problem. After playing around with "udevsythesize" it felt stupid to try to compose all the events from sysfs values which will never be exactly the same as the kernel event.
This patch adds a "uevent" file to all class/block/bus-devices. Writing to this file, will just emit the hotplug event from the kernel again. udevstart and all the coldplug logic can be 3 lines of shell-script now. Boots fine and is _very_ fast on my box.

Quoted 7 lines
Quoted 1 line

What do you think?

It looks really nice, but will we still be able to differientate coldplug events in udev rules?
For example, in Mandriva, we do PCI coldplug for USB controllers only, because we handle other stuff (sound, network, ...) later in services. We used to rely on UDEV_START in udev rules.

Not with this simple patch. It would be possible by adding an additional parameter to kobject_hotplug() to add an aditional key. Or we could use a different ACTION value and map it with udev...

But unlike udevstart/udevsynthesize, you have complete control which events are generated, cause you will do it from a shell script and not with a binary. Wouldn't it work, to just trigger the events for the usb controllers and and leave the others alone?

To play with it, I use this stupid hack in an early init-script and it works without udevstart or any other coldplug logic. After mounting tmpfs, creating /dev/null, disabling /sbin/hotplug and starting udevd, it creates the tty devices, waits for the events to finish, then sends out all remaining events to finish asynchronously:
...

  # regenerate events by triggering sysfs
  for i in /sys/class/t*/*/uevent; do echo 1 > $i; done
  # wait for async tty events to finish
  while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') -gt 1 ]; do
      sleep 0.1
  done
  for i in /sys/class/[!t]*/*/uevent; do echo 1 > $i; done
  for i in /sys/block/*/uevent; do echo 1 > $i; done
  for i in /sys/block/*/*[1-9]/uevent; do echo 1 > $i; done
  for i in /sys/bus/*/devices/*/uevent; do echo 1 > $i; done
  ...

To make this reliable, we would need to trigger some events in a defined order, like the device mapper events after the block device events and similar, and may need some checkpoints to make sure that certain devices are available at a specific point...

Anyway, it works on two of my boxes and is the fastest udev/coldplug bootup, I've ever seen. :)

Thanks,
Kay

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#4 lore raw
In reply to Kay Sievers
Quoted 6 lines · Kay Sievers
Quoted 5 lines

It looks really nice, but will we still be able to differientate coldplug events in udev rules?
For example, in Mandriva, we do PCI coldplug for USB controllers only, because we handle other stuff (sound, network, ...) later in services. We used to rely on UDEV_START in udev rules.

Quoted 8 lines

Not with this simple patch. It would be possible by adding an additional parameter to kobject_hotplug() to add an aditional key. Or we could use a different ACTION value and map it with udev...

But unlike udevstart/udevsynthesize, you have complete control which events are generated, cause you will do it from a shell script and not with a binary. Wouldn't it work, to just trigger the events for the usb controllers and and leave the others alone?

Actually, we also need to know the class of the pci device, that's why
it was handy to use an udev rule.
But of course, we could use something like that:
for i in /sys/bus/pci/devices/*; do egrep -q '0x0c03[012]0' $i/class && echo 1 > $i/uevent; done

Quoted 5 lines

To play with it, I use this stupid hack in an early init-script and it works without udevstart or any other coldplug logic. After mounting tmpfs, creating /dev/null, disabling /sbin/hotplug and starting udevd, it creates the tty devices, waits for the events to finish, then sends out all remaining events to finish asynchronously:

Thanks for the explanation

Quoted 2 lines

Anyway, it works on two of my boxes and is the fastest udev/coldplug bootup, I've ever seen. :)

Strange it's that better, udevstart/synthetize only browsed the sysfs directories and added some environment variables. Browsing with bash should be almost as slow.

Signature · 13 lines
Olivier Blin
Mandriva



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
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 Kay Sievers
Quoted 6 lines · Kay Sievers

To play with it, I use this stupid hack in an early init-script and it works without udevstart or any other coldplug logic. After mounting tmpfs, creating /dev/null, disabling /sbin/hotplug and starting udevd, it creates the tty devices, waits for the events to finish, then sends out all remaining events to finish asynchronously:
...

Quoted 7 lines
  # regenerate events by triggering sysfs
  for i in /sys/class/t*/*/uevent; do echo 1 > $i; done
  # wait for async tty events to finish
  while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') -gt 1 ]; do
      sleep 0.1
  done

There's a much better way to do this! If there's a guarantee that a "write to uevent" will cause a uevent, you can simply use the udev rules to make sure that udev has fired for each uevent you caused to be generated.

No need to grovel for udev processes, etc.

Scott

Signature · 2 lines
Scott James Remnant
[email protected]
#6 lore raw
In reply to Kay Sievers
Quoted 15 lines · Scott James Remnant
Quoted 6 lines · Kay Sievers

To play with it, I use this stupid hack in an early init-script and it works without udevstart or any other coldplug logic. After mounting tmpfs, creating /dev/null, disabling /sbin/hotplug and starting udevd, it creates the tty devices, waits for the events to finish, then sends out all remaining events to finish asynchronously:
...

Quoted 7 lines
  # regenerate events by triggering sysfs
  for i in /sys/class/t*/*/uevent; do echo 1 > $i; done
  # wait for async tty events to finish
  while [ $(cat /proc/*/status 2> /dev/null | grep -c -E '^Name:.udevd?$') -gt 1 ]; do
      sleep 0.1
  done
Quoted 6 lines

There's a much better way to do this! If there's a guarantee that a "write to uevent" will cause a uevent, you can simply use the udev rules to make sure that udev has fired for each uevent you caused to be generated.

No need to grovel for udev processes, etc.

I don't see how to use a udev rules to continue the init script which depends on the tty's to be around after that. Care to explain?

Kay

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#7 lore raw
In reply to Kay Sievers
Quoted 8 lines · David Brownell
Quoted 6 lines

This patch adds a "uevent" file to all class/block/bus-devices. Writing to this file, will just emit the hotplug event from the kernel again. udevstart and all the coldplug logic can be 3 lines of shell-script now. Boots fine and is _very_ fast on my box.

What do you think?

It only issues the "add" event, but otherwise the idea is intriguing.

There's no way to re-issue the "remove" event, as the object is already gone :)

Quoted 2 lines

For paranoia's sake, it might be good to flag these events as being replays/fakes.

How? And why? The sequence number will be different from the original, if you really want to pay attention to that.

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#8 lore raw
In reply to Kay Sievers
Quoted 3 lines · Kay Sievers

I don't see how to use a udev rules to continue the init script which depends on the tty's to be around after that. Care to explain?

e.g. for each of /sys/class/t*/*, write the name into a file (/tmp/waiting) and write to the uevent... in a udev rule for events, remove the line from the /tmp/waiting file.

Sleep until the /tmp/waiting file is zero bytes in size.

Ok, that's just as hacky as grovelling around in ps I guess, but at least it has the advantage that there's no possibility of no udev processes having been started by the next line of shell - which there is with your example.

There's almost certainly a more elegant way, but basically mark the events you're waiting for and wait for them all to come back.

Scott

Signature · 2 lines
Scott James Remnant
[email protected]
#9 lore raw
In reply to Kay Sievers
Quoted 12 lines · Scott James Remnant
Quoted 3 lines · Kay Sievers

I don't see how to use a udev rules to continue the init script which depends on the tty's to be around after that. Care to explain?

e.g. for each of /sys/class/t*/*, write the name into a file (/tmp/waiting) and write to the uevent... in a udev rule for events, remove the line from the /tmp/waiting file.

Sleep until the /tmp/waiting file is zero bytes in size.

Quoted 7 lines

Ok, that's just as hacky as grovelling around in ps I guess, but at least it has the advantage that there's no possibility of no udev processes having been started by the next line of shell - which there is with your example.

There's almost certainly a more elegant way, but basically mark the events you're waiting for and wait for them all to come back.

We could have a lock directory, in which a lock file would be added for each event (using the full path with '/' replaced by '%' for example). This lock file would be removed once udev is done processing the event. But is it easy to remove a lock file when a PROGRAM or RUN rule is used? Maybe by catching signals of this program.

Signature · 13 lines
Olivier Blin
Mandriva



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
#10 lore raw
In reply to Kay Sievers
Quoted 5 lines · Olivier Blin
Quoted 5 lines

Ok, that's just as hacky as grovelling around in ps I guess, but at least it has the advantage that there's no possibility of no udev processes having been started by the next line of shell - which there is with your example.

Quoted 8 lines
Quoted 2 lines

There's almost certainly a more elegant way, but basically mark the events you're waiting for and wait for them all to come back.

We could have a lock directory, in which a lock file would be added for each event (using the full path with '/' replaced by '%' for example). This lock file would be removed once udev is done processing the event. But is it easy to remove a lock file when a PROGRAM or RUN rule is used? Maybe by catching signals of this program.

Realistically, how often are you doing udev coldplug with a writable system filesystem? I'd suspect at least in our case, any coldplug would be well before the root fs is read/write.

Bill

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#11 lore raw
In reply to Kay Sievers
Quoted 15 lines · Bill Nottingham
Quoted 5 lines · Olivier Blin
Quoted 5 lines

Ok, that's just as hacky as grovelling around in ps I guess, but at least it has the advantage that there's no possibility of no udev processes having been started by the next line of shell - which there is with your example.

Quoted 8 lines
Quoted 2 lines

There's almost certainly a more elegant way, but basically mark the events you're waiting for and wait for them all to come back.

We could have a lock directory, in which a lock file would be added for each event (using the full path with '/' replaced by '%' for example). This lock file would be removed once udev is done processing the event. But is it easy to remove a lock file when a PROGRAM or RUN rule is used? Maybe by catching signals of this program.

Quoted 3 lines

Realistically, how often are you doing udev coldplug with a writable system filesystem? I'd suspect at least in our case, any coldplug would be well before the root fs is read/write.

That's right, coldplug is often done when the root fs isn't writable yet. But it isn't really a problem, we could use something like /dev/.udevdb/, for example /dev/.udevlock/

Signature · 13 lines
Olivier Blin
Mandriva



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
#12 lore raw
In reply to Kay Sievers
Quoted 10 lines · David Brownell
Quoted 6 lines
Quoted 3 lines
Quoted 1 line

What do you think?

It only issues the "add" event, but otherwise the idea is intriguing.

There's no way to re-issue the "remove" event, as the object is already gone :)

There are more event types than just "add" (and "remove") ...

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

For paranoia's sake, it might be good to flag these events as being replays/fakes.

How? And why? The sequence number will be different from the original, if you really want to pay attention to that.

How? Add some environment variable, maybe HOTPLUG_REPLAY=y.

Ok, how would you do that with our current kernel infrastructure?

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#13 lore raw
In reply to Kay Sievers
Quoted 3 lines · Kay Sievers

From: Kay Sievers <[email protected]>
Subject: add sysfs attr to re-emit device hotplug event

Did this patch ever go any further towards the kernel? Trying to roadmap our udev plans this week, and I'd love to be able to use this instead of the current udevstart stuff.

Scott

Signature · 2 lines
Scott James Remnant
[email protected]
#14 lore raw
In reply to Kay Sievers
Quoted 8 lines · Scott James Remnant
Quoted 3 lines · Kay Sievers

From: Kay Sievers <[email protected]>
Subject: add sysfs attr to re-emit device hotplug event

Did this patch ever go any further towards the kernel? Trying to roadmap our udev plans this week, and I'd love to be able to use this instead of the current udevstart stuff.

It hit Linus's tree about 2 minutes ago :)

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#15 lore raw
In reply to Kay Sievers
Quoted 12 lines · Greg KH
Quoted 9 lines · Scott James Remnant
Quoted 5 lines · Kay Sievers

From: Kay Sievers <[email protected]>
Subject: add sysfs attr to re-emit device hotplug event

Quoted 9 lines
Quoted 5 lines

Did this patch ever go any further towards the kernel? Trying to roadmap our udev plans this week, and I'd love to be able to use this instead of the current udevstart stuff.

It hit Linus's tree about 2 minutes ago :)

Are you basically saying that it will be in 2.6.15-rc1?

Signature · 12 lines
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
#16 lore raw
In reply to Kay Sievers
Quoted 20 lines · Alexander E. Patrakov
Quoted 18 lines · Greg KH
Quoted 14 lines · Scott James Remnant
Quoted 5 lines · Kay Sievers

From: Kay Sievers <[email protected]>
Subject: add sysfs attr to re-emit device hotplug event

Did this patch ever go any further towards the kernel? Trying to roadmap our udev plans this week, and I'd love to be able to use this instead of the current udevstart stuff.

Quoted 4 lines
Quoted 3 lines

It hit Linus's tree about 2 minutes ago :)

Are you basically saying that it will be in 2.6.15-rc1?

Yes.

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel