[RFC] coldplug - emit hotplug events from sysfs

[RFC] coldplug - emit hotplug events from sysfs

[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?

Thanks,
Kay

------------
From: Kay Sievers <kay.sievers@suse.de>
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

Signed-off-by: Kay Sievers <kay.sievers@suse.de>
---

diff --git a/drivers/base/class.c b/drivers/base/class.c
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -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);
diff --git a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -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...
diff --git a/drivers/block/genhd.c b/drivers/block/genhd.c
--- a/drivers/block/genhd.c
+++ b/drivers/block/genhd.c
@@ -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,
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -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,
diff --git a/include/linux/device.h b/include/linux/device.h
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -190,6 +190,18 @@ struct class_attribute class_attr_##_nam
 extern int class_create_file(struct class *, const struct class_attribute *);
 extern void class_remove_file(struct class *, const struct class_attribute *);
 
+struct class_device_attribute {
+	struct attribute	attr;
+	ssize_t (*show)(struct class_device *, char * buf);
+	ssize_t (*store)(struct class_device *, const char * buf, size_t count);
+};
+
+#define CLASS_DEVICE_ATTR(_name,_mode,_show,_store)		\
+struct class_device_attribute class_device_attr_##_name = 	\
+	__ATTR(_name,_mode,_show,_store)
+
+extern int class_device_create_file(struct class_device *, 
+				    const struct class_device_attribute *);
 
 struct class_device {
 	struct list_head	node;
@@ -198,6 +210,7 @@ struct class_device {
 	struct class		* class;	/* required */
 	dev_t			devt;		/* dev_t, creates the sysfs "dev" */
 	struct class_device_attribute *devt_attr;
+	struct class_device_attribute uevent_attr;
 	struct device		* dev;		/* not necessary, but nice to have */
 	void			* class_data;	/* class-specific data */
 
@@ -228,18 +241,6 @@ extern int class_device_rename(struct cl
 extern struct class_device * class_device_get(struct class_device *);
 extern void class_device_put(struct class_device *);
 
-struct class_device_attribute {
-	struct attribute	attr;
-	ssize_t (*show)(struct class_device *, char * buf);
-	ssize_t (*store)(struct class_device *, const char * buf, size_t count);
-};
-
-#define CLASS_DEVICE_ATTR(_name,_mode,_show,_store)		\
-struct class_device_attribute class_device_attr_##_name = 	\
-	__ATTR(_name,_mode,_show,_store)
-
-extern int class_device_create_file(struct class_device *, 
-				    const struct class_device_attribute *);
 extern void class_device_remove_file(struct class_device *, 
 				     const struct class_device_attribute *);
 extern int class_device_create_bin_file(struct class_device *,
@@ -266,6 +267,20 @@ extern struct class_device *class_device
 extern void class_device_destroy(struct class *cls, dev_t devt);
 
 
+/* interface for exporting device attributes */
+struct device_attribute {
+	struct attribute	attr;
+	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
+			char *buf);
+	ssize_t (*store)(struct device *dev, struct device_attribute *attr,
+			 const char *buf, size_t count);
+};
+
+#define DEVICE_ATTR(_name,_mode,_show,_store) \
+struct device_attribute dev_attr_##_name = __ATTR(_name,_mode,_show,_store)
+
+extern int device_create_file(struct device *device, struct device_attribute * entry);
+extern void device_remove_file(struct device * dev, struct device_attribute * attr);
 struct device {
 	struct klist		klist_children;
 	struct klist_node	knode_parent;		/* node in sibling list */
@@ -275,6 +290,7 @@ struct device {
 
 	struct kobject kobj;
 	char	bus_id[BUS_ID_SIZE];	/* position on parent bus */
+	struct device_attribute uevent_attr;
 
 	struct semaphore	sem;	/* semaphore to synchronize calls to
 					 * its driver.
@@ -343,23 +359,6 @@ extern int  device_attach(struct device 
 extern void driver_attach(struct device_driver * drv);
 
 
-/* driverfs interface for exporting device attributes */
-
-struct device_attribute {
-	struct attribute	attr;
-	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
-			char *buf);
-	ssize_t (*store)(struct device *dev, struct device_attribute *attr,
-			 const char *buf, size_t count);
-};
-
-#define DEVICE_ATTR(_name,_mode,_show,_store) \
-struct device_attribute dev_attr_##_name = __ATTR(_name,_mode,_show,_store)
-
-
-extern int device_create_file(struct device *device, struct device_attribute * entry);
-extern void device_remove_file(struct device * dev, struct device_attribute * attr);
-
 /*
  * Platform "fixup" functions - allow the platform to have their say
  * about devices and actions that the general device layer doesn't
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Scott James Remnant]

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

On Sat, 2005-10-01 at 14:49 +0200, Kay Sievers wrote:

> 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
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] coldplug - emit hotplug events from sysfs

[Olivier Blin]

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

> 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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Kay Sievers]

On Mon, Oct 03, 2005 at 12:29:03PM +0200, Olivier Blin wrote:
> Kay Sievers <kay.sievers@vrfy.org> writes:
> 
> > 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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Olivier Blin]

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

>> 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?

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

> 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

> 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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Scott James Remnant]

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

On Mon, 2005-10-03 at 14:21 +0200, Kay Sievers wrote:

> 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
> 
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
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] coldplug - emit hotplug events from sysfs

[Kay Sievers]

On Mon, Oct 03, 2005 at 04:21:49PM +0100, Scott James Remnant wrote:
> On Mon, 2005-10-03 at 14:21 +0200, Kay Sievers wrote:
> 
> > 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
> > 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Greg KH]

On Mon, Oct 03, 2005 at 08:58:18AM -0700, David Brownell wrote:
> > 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 :)

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Scott James Remnant]

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

On Mon, 2005-10-03 at 17:29 +0200, Kay Sievers wrote:

> 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
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] coldplug - emit hotplug events from sysfs

[Olivier Blin]

Scott James Remnant <scott@ubuntu.com> writes:

> On Mon, 2005-10-03 at 17:29 +0200, Kay Sievers wrote:
>
>> 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.

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.

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Bill Nottingham]

Olivier Blin (oblin@mandriva.com) said: 
> > 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.

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Olivier Blin]

Bill Nottingham <notting@redhat.com> writes:

> Olivier Blin (oblin@mandriva.com) said: 
>> > 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.
>
> 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/

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Greg KH]

On Mon, Oct 03, 2005 at 10:57:50AM -0700, David Brownell wrote:
> > > > 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") ...
> 
> 
> > > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Scott James Remnant]

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

On Sat, 2005-10-01 at 14:49 +0200, Kay Sievers wrote:

> From: Kay Sievers <kay.sievers@suse.de>
> 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
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] coldplug - emit hotplug events from sysfs

[Greg KH]

On Fri, Oct 28, 2005 at 04:12:09PM -0400, Scott James Remnant wrote:
> On Sat, 2005-10-01 at 14:49 +0200, Kay Sievers wrote:
> 
> > From: Kay Sievers <kay.sievers@suse.de>
> > 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Alexander E. Patrakov]

Greg KH wrote:

>On Fri, Oct 28, 2005 at 04:12:09PM -0400, Scott James Remnant wrote:
>  
>
>>On Sat, 2005-10-01 at 14:49 +0200, Kay Sievers wrote:
>>
>>    
>>
>>>From: Kay Sievers <kay.sievers@suse.de>
>>>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 :)
>  
>
Are you basically saying that it will be in 2.6.15-rc1?

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] coldplug - emit hotplug events from sysfs

[Greg KH]

On Sat, Oct 29, 2005 at 08:29:31AM +0600, Alexander E. Patrakov wrote:
> Greg KH wrote:
> 
> >On Fri, Oct 28, 2005 at 04:12:09PM -0400, Scott James Remnant wrote:
> > 
> >
> >>On Sat, 2005-10-01 at 14:49 +0200, Kay Sievers wrote:
> >>
> >>   
> >>
> >>>From: Kay Sievers <kay.sievers@suse.de>
> >>>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 :)
> > 
> >
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel