Delayed hotplug events

Delayed hotplug events

[Hannes Reinecke]

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

Hi all,

currently we have the problem that the driver core might send out 
hotplug events even though the initialisation of a device has not been 
finished; worse, we might get an "add" followed by an "remove" event if 
the device fails to initialise properly, with the corresponding device 
never appearing in sysfs properly.
This is due to the design of the driver core:
a call to device_register will trigger a hotplug event, but any sysfs 
attributes which are added _after_ device_register() will in fact 
created after the hotplug event has been triggered. For the unbelievers, 
look at drivers/scsi/scsi_sysfs.c:scsi_sysfs_add_sdev().
This leads to all sorts of nasty race conditions and waiting loops in 
the hotplug agents.

To solve this I've wrapped up a patch for delaying / suspending hotplug 
events until they are explicitely enabled again.
As an example of how it should be used I've patched 
drivers/scsi/scsi_sysfs.c:scsi_sysfs_add_sdev(), so that the device 
"add" event will now be triggered only _after_ the device has been 
initialised properly, including all sysfs attributes.

Is this approach feasible or am I completely off kilter here?
And if the latter, how should it be solved properly?

(Note: this is a proof of concept. No devices have been harmed in 
creating this patch. I just wanted to get a general opinion before 
venturing any further.)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

[-- Attachment #2: delay-hotplug-events.patch --]
[-- Type: text/x-patch, Size: 3864 bytes --]

--- ./lib/kobject.c.orig	2004-06-17 09:18:27.000000000 +0200
+++ ./lib/kobject.c	2004-06-17 12:59:55.000000000 +0200
@@ -472,6 +472,53 @@
 		kobject_cleanup(kobj);
 }
 
+static int kobject_hotplug_filter_all(struct kset *kset, struct kobject *kobj)
+{
+	return 0;
+}
+
+/**
+ *      kobject_disable_events - filter out all hotplug events
+ *      @kobj:  object
+ *
+ */
+
+void kobject_disable_events(struct kobject * kobj )
+{
+	struct kset_hotplug_ops *delayed_ops;
+
+	if (kobj && kobj->kset) {
+		down_write(&kobj->kset->subsys->rwsem);
+
+		delayed_ops = kobj->kset->hotplug_ops;
+		kobj->kset->hotplug_ops_stored = delayed_ops;
+
+		delayed_ops->filter = kobject_hotplug_filter_all;
+		kobj->kset->hotplug_ops = delayed_ops;
+
+		up_write(&kobj->kset->subsys->rwsem);
+	}
+}	
+
+/**
+ *      kobject_enable_events - reset hotplug filter to original value
+ *      @kobj:  object
+ *
+ */
+
+void kobject_enable_events(struct kobject * kobj )
+{
+	struct kset_hotplug_ops *delayed_ops;
+
+	if (kobj && kobj->kset && kobj->kset->hotplug_ops_stored) {
+		down_write(&kobj->kset->subsys->rwsem);
+
+		kobj->kset->hotplug_ops = kobj->kset->hotplug_ops_stored;
+		kobj->kset->hotplug_ops_stored = NULL;
+
+		up_write(&kobj->kset->subsys->rwsem);
+	}
+}	
 
 /**
  *	kset_init - initialize a kset for use
@@ -635,6 +682,8 @@
 EXPORT_SYMBOL(kobject_del);
 EXPORT_SYMBOL(kobject_rename);
 EXPORT_SYMBOL(kobject_hotplug);
+EXPORT_SYMBOL(kobject_enable_events);
+EXPORT_SYMBOL(kobject_disable_events);
 
 EXPORT_SYMBOL(kset_register);
 EXPORT_SYMBOL(kset_unregister);
--- ./drivers/base/core.c.orig	2004-06-17 09:03:58.000000000 +0200
+++ ./drivers/base/core.c	2004-06-17 13:06:29.581368704 +0200
@@ -271,6 +271,25 @@
 	return device_add(dev);
 }
 
+void device_suspend_hotplug(struct device *dev)
+{
+	get_device(dev);
+
+	kobject_disable_events(&dev->kobj);
+
+	put_device(dev);
+}
+
+void device_resume_hotplug(struct device *dev)
+{
+	get_device(dev);
+
+	kobject_enable_events(&dev->kobj);
+	
+	kobject_hotplug("add", &dev->kobj);
+
+	put_device(dev);
+}
 
 /**
  *	get_device - increment reference count for device.
@@ -405,3 +424,5 @@
 
 EXPORT_SYMBOL(device_create_file);
 EXPORT_SYMBOL(device_remove_file);
+EXPORT_SYMBOL(device_suspend_hotplug);
+EXPORT_SYMBOL(device_resume_hotplug);
--- ./drivers/scsi/scsi_sysfs.c.orig	2004-06-17 13:00:45.000000000 +0200
+++ ./drivers/scsi/scsi_sysfs.c	2004-06-17 13:03:13.071318353 +0200
@@ -379,6 +379,7 @@
 	if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
 		return error;
 
+	device_suspend_hotplug(&sdev->sdev_gendev);
 	error = device_add(&sdev->sdev_gendev);
 	if (error) {
 		printk(KERN_INFO "error 1\n");
@@ -439,6 +440,8 @@
  		}
  	}
 
+	device_resume_hotplug(&sdev->sdev_gendev);
+
  out:
 	return error;
 
--- ./include/linux/kobject.h.orig	2004-06-17 11:22:29.000000000 +0200
+++ ./include/linux/kobject.h	2004-06-17 12:55:06.000000000 +0200
@@ -47,6 +47,8 @@
 
 extern int kobject_add(struct kobject *);
 extern void kobject_del(struct kobject *);
+extern void kobject_enable_events(struct kobject *kobj);
+extern void kobject_disable_events(struct kobject *kobj);
 
 extern int kobject_rename(struct kobject *, char *new_name);
 
@@ -96,6 +98,7 @@
 	struct list_head	list;
 	struct kobject		kobj;
 	struct kset_hotplug_ops	* hotplug_ops;
+	struct kset_hotplug_ops	* hotplug_ops_stored;
 };
 
 
--- ./include/linux/device.h.orig	2004-06-17 12:14:21.000000000 +0200
+++ ./include/linux/device.h	2004-06-17 12:14:56.000000000 +0200
@@ -332,6 +332,8 @@
 extern void device_bind_driver(struct device * dev);
 extern void device_release_driver(struct device * dev);
 extern void driver_attach(struct device_driver * drv);
+extern void device_suspend_hotplug(struct device *dev);
+extern void device_resume_hotplug(struct device *dev);
 
 
 /* driverfs interface for exporting device attributes */

Re: Delayed hotplug events

[Greg KH]

On Thu, Jun 17, 2004 at 01:21:48PM +0200, Hannes Reinecke wrote:
> Hi all,
> 
> currently we have the problem that the driver core might send out 
> hotplug events even though the initialisation of a device has not been 
> finished; worse, we might get an "add" followed by an "remove" event if 
> the device fails to initialise properly, with the corresponding device 
> never appearing in sysfs properly.

Exactly, that is why udevd handles the reordering of hotplug events.  It
seems that suse is not using udevd, and hence needs to handle these out
of order events somehow :)

> This is due to the design of the driver core:
> a call to device_register will trigger a hotplug event, but any sysfs 
> attributes which are added _after_ device_register() will in fact 
> created after the hotplug event has been triggered.

This is a known "issue", nothing new here.

> For the unbelievers, look at
> drivers/scsi/scsi_sysfs.c:scsi_sysfs_add_sdev().  This leads to all
> sorts of nasty race conditions and waiting loops in the hotplug
> agents.
> 
> To solve this I've wrapped up a patch for delaying / suspending hotplug 
> events until they are explicitely enabled again.

Nope, solve this in userspace, not with a patch like this.


> As an example of how it should be used I've patched 
> drivers/scsi/scsi_sysfs.c:scsi_sysfs_add_sdev(), so that the device 
> "add" event will now be triggered only _after_ the device has been 
> initialised properly, including all sysfs attributes.
> 
> Is this approach feasible or am I completely off kilter here?

Off kilter :)

> And if the latter, how should it be solved properly?

In userspace, with things like udevd and just simply sleeping for a
short ammount of time to allow the kernel to catch up to userspace :)

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Oliver Neukum]

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

Am Donnerstag, 17. Juni 2004 20:09 schrieb Greg KH:
> > And if the latter, how should it be solved properly?
> 
> In userspace, with things like udevd and just simply sleeping for a
> short ammount of time to allow the kernel to catch up to userspace :)

That, frankly, is voodoo. As for reordering, it is debateable. But the
need to wait for a _guessed_ amount of time is a clear design error.
There's no upper bound you could give for appearance of the sysfs
files.

	Regards
		Oliver

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

iD8DBQFA0fdubuJ1a+1Sn8oRAjk4AJ4g4IqzwbZ5W2ZxZysbuDSv10HsIACgzDVp
/pRa2PWXI3TvaeXHx6lZKZA=TTb5
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[linas]

On Thu, Jun 17, 2004 at 09:56:25PM +0200, Oliver Neukum wrote:
> Am Donnerstag, 17. Juni 2004 20:09 schrieb Greg KH:
> > > And if the latter, how should it be solved properly?
> > 
> > In userspace, with things like udevd and just simply sleeping for a
> > short ammount of time to allow the kernel to catch up to userspace :)
> 
> That, frankly, is voodoo. As for reordering, it is debateable. But the
> need to wait for a _guessed_ amount of time is a clear design error.
> There's no upper bound you could give for appearance of the sysfs
> files.

I'd agree.  If the disk controller is attached to some fabric, and the 
fabric has gone epileptic or is rebooting itself or hot-failing over 
to some alternate configuration, then I'd imagine it might take either 
tens of seconds or some other unpredicatable amount of time to come up.
Yes, I suppose that some user-space script could poll the device 
to make sure its 'really up', but that seems like a kludge.  Makes
the million-dollar fabric behave as if it was some cheapo USB device 
that couldn't be bothered to tell anyone if it has media inserted in it. 

By contrast, I can't see what's architecturally unclean about 
having device drivers make the call as to when they think they
are finally up and ready to go, e.g. by making one puny subroutine 
call at the end of thier init sequence.  Why would this be a bad idea?

--linas



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Patrick Mansfield]

On Thu, Jun 17, 2004 at 11:09:30AM -0700, Greg KH wrote:
> On Thu, Jun 17, 2004 at 01:21:48PM +0200, Hannes Reinecke wrote:

> > As an example of how it should be used I've patched 
> > drivers/scsi/scsi_sysfs.c:scsi_sysfs_add_sdev(), so that the device 
> > "add" event will now be triggered only _after_ the device has been 
> > initialised properly, including all sysfs attributes.
> > 
> > Is this approach feasible or am I completely off kilter here?
> 
> Off kilter :)
> 
> > And if the latter, how should it be solved properly?
> 
> In userspace, with things like udevd and just simply sleeping for a
> short ammount of time to allow the kernel to catch up to userspace :)

I thought you were going to fix this in 2.7, or do you mean for 2.6, fix
it in userspace?

Reference:

http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m\x108034761409426&w=2

-- Patrick Mansfield


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Greg KH]

On Thu, Jun 17, 2004 at 04:29:20PM -0700, Patrick Mansfield wrote:
> On Thu, Jun 17, 2004 at 11:09:30AM -0700, Greg KH wrote:
> > On Thu, Jun 17, 2004 at 01:21:48PM +0200, Hannes Reinecke wrote:
> 
> > > As an example of how it should be used I've patched 
> > > drivers/scsi/scsi_sysfs.c:scsi_sysfs_add_sdev(), so that the device 
> > > "add" event will now be triggered only _after_ the device has been 
> > > initialised properly, including all sysfs attributes.
> > > 
> > > Is this approach feasible or am I completely off kilter here?
> > 
> > Off kilter :)
> > 
> > > And if the latter, how should it be solved properly?
> > 
> > In userspace, with things like udevd and just simply sleeping for a
> > short ammount of time to allow the kernel to catch up to userspace :)
> 
> I thought you were going to fix this in 2.7, or do you mean for 2.6, fix
> it in userspace?

Yes, for 2.6 do it in userspace.  For 2.7, I'm going to revisit this to
try to keep this from happening.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Greg KH]

On Thu, Jun 17, 2004 at 09:56:25PM +0200, Oliver Neukum wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Donnerstag, 17. Juni 2004 20:09 schrieb Greg KH:
> > > And if the latter, how should it be solved properly?
> > 
> > In userspace, with things like udevd and just simply sleeping for a
> > short ammount of time to allow the kernel to catch up to userspace :)
> 
> That, frankly, is voodoo. As for reordering, it is debateable. But the
> need to wait for a _guessed_ amount of time is a clear design error.
> There's no upper bound you could give for appearance of the sysfs
> files.

I agree there is no upper bound, just make sure that the directory for
the device is still present, and you can sleep for as long as you want.
:)

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Greg KH]

On Thu, Jun 17, 2004 at 03:22:07PM -0500, linas@austin.ibm.com wrote:
> 
> By contrast, I can't see what's architecturally unclean about 
> having device drivers make the call as to when they think they
> are finally up and ready to go, e.g. by making one puny subroutine 
> call at the end of thier init sequence.  Why would this be a bad idea?

Because it would be a major architecture change in the middle of a
stable kernel series.  I'm not going to agree to do that at this time.

Sorry,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Oliver Neukum]

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

Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
> On Thu, Jun 17, 2004 at 03:22:07PM -0500, linas@austin.ibm.com wrote:
> > 
> > By contrast, I can't see what's architecturally unclean about 
> > having device drivers make the call as to when they think they
> > are finally up and ready to go, e.g. by making one puny subroutine 
> > call at the end of thier init sequence.  Why would this be a bad idea?
> 
> Because it would be a major architecture change in the middle of a
> stable kernel series.  I'm not going to agree to do that at this time.

If you are willing to use a model of a blocking counter you can confine
the changes to just the actual hotplug generation. The change is well
encapsuled. Drivers not caring about the block/unblock affair simply get
the old behavior.
It's less elegant than waiting for the specific files, but workable.

	Regards
		Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0p1jbuJ1a+1Sn8oRAosaAKCo2E+jVkO4qKoGCmmST0eY731gxACePghX
GYEIgWP5U8/1nl29ScApO2M=1LI9
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Hannes Reinecke]

Oliver Neukum wrote:
> Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
> 
>>>On Thu, Jun 17, 2004 at 03:22:07PM -0500, linas@austin.ibm.com wrote:
>>>
>>>>By contrast, I can't see what's architecturally unclean about 
>>>>having device drivers make the call as to when they think they
>>>>are finally up and ready to go, e.g. by making one puny subroutine 
>>>>call at the end of thier init sequence.  Why would this be a bad idea?
>>>
>>>Because it would be a major architecture change in the middle of a
>>>stable kernel series.  I'm not going to agree to do that at this time.
> 
> 
> If you are willing to use a model of a blocking counter you can confine
> the changes to just the actual hotplug generation. The change is well
> encapsuled. Drivers not caring about the block/unblock affair simply get
> the old behavior.
> It's less elegant than waiting for the specific files, but workable.
> 
You mean add an additional sysfs attribute which serves as an checkpoint 
(i.e. if this attribute exists, the initialisation is done)?
Neat. Fixing the drivers (or even adding another generic function to 
drivers/base/core.c) should be pretty straightforward.
One could even add another ENV which contains the name of the checkpoint 
attribute; this way it's pretty clear to any script whether it needs to 
wait or not.
This would also solve the timeout problem, as we could teach udevd to 
wait for this checkpoint attribute to appear; if a matching 'remove' 
event is received before the checkpoint is visible, udevd could just 
drop both events.
Greg: acceptable?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Oliver Neukum]

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

Am Freitag, 18. Juni 2004 10:12 schrieb Hannes Reinecke:
> Oliver Neukum wrote:
> > Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
> > 
> >>>On Thu, Jun 17, 2004 at 03:22:07PM -0500, linas@austin.ibm.com wrote:
> >>>
> >>>>By contrast, I can't see what's architecturally unclean about 
> >>>>having device drivers make the call as to when they think they
> >>>>are finally up and ready to go, e.g. by making one puny subroutine 
> >>>>call at the end of thier init sequence.  Why would this be a bad idea?
> >>>
> >>>Because it would be a major architecture change in the middle of a
> >>>stable kernel series.  I'm not going to agree to do that at this time.
> > 
> > 
> > If you are willing to use a model of a blocking counter you can confine
> > the changes to just the actual hotplug generation. The change is well
> > encapsuled. Drivers not caring about the block/unblock affair simply get
> > the old behavior.
> > It's less elegant than waiting for the specific files, but workable.
> > 
> You mean add an additional sysfs attribute which serves as an checkpoint 
> (i.e. if this attribute exists, the initialisation is done)?

No, I would consider that redundant. If you let events queue up until
a counter reaches zero, you can guarantee that there's time to generate
all files being refered to in the event. There's no need to export it.

	Regards
		Oliver

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

iD8DBQFA0qwWbuJ1a+1Sn8oRAvwcAKDIJwW6co2dXA312SJSSbDsQa4MmACg6c3s
YNAlkNzDMXb4wfMcFiltqoQ=J6YD
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Hannes Reinecke]

Oliver Neukum wrote:
> Am Freitag, 18. Juni 2004 10:12 schrieb Hannes Reinecke:
> 
>>>Oliver Neukum wrote:
>>>
[ .. ]
>>>>If you are willing to use a model of a blocking counter you can confine
>>>>the changes to just the actual hotplug generation. The change is well
>>>>encapsuled. Drivers not caring about the block/unblock affair simply get
>>>>the old behavior.
>>>>It's less elegant than waiting for the specific files, but workable.
>>>>
>>>
>>>You mean add an additional sysfs attribute which serves as an checkpoint 
>>>(i.e. if this attribute exists, the initialisation is done)?
> 
> 
> No, I would consider that redundant. If you let events queue up until
> a counter reaches zero, you can guarantee that there's time to generate
> all files being refered to in the event. There's no need to export it.
> 
Hmm. I see. But isn't this approach conceptually identical to my patch? 
I mean, you're blocking events until a semaphore is set, whereas I'm 
dropping events during the critical section and generate them again. No 
big change.

And it doesn't change the main issue, which is that the behaviour of the 
hotplug subsystem is changed (i.e. the time when events are sent).
Adding just another attribute doesn't change it, as it's up to the 
drivers to generate sysfs attributes.

Cheers,

hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Oliver Neukum]

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


> > No, I would consider that redundant. If you let events queue up until
> > a counter reaches zero, you can guarantee that there's time to generate
> > all files being refered to in the event. There's no need to export it.
> > 
> Hmm. I see. But isn't this approach conceptually identical to my patch? 
> I mean, you're blocking events until a semaphore is set, whereas I'm 
> dropping events during the critical section and generate them again. No 
> big change.

Conceptually it makes no difference. But queueing events can be
encapsulated at the point the tasks are actually spawned. I don't see
the possibilty if you have to regenerate events.
I may, however, be wrong.

> And it doesn't change the main issue, which is that the behaviour of the 
> hotplug subsystem is changed (i.e. the time when events are sent).
> Adding just another attribute doesn't change it, as it's up to the 
> drivers to generate sysfs attributes.

No. An additional attribute is visible. Waiting is not. Assuming that the
attribute files are not there as the event is evaluated is _clearly_ wrong.
If you delay the events full compatibility is kept.
Waiting doesn't change anything fundamentally. It just makes sure that
the hotplug subsystem always behaves in a way it may behave currently.

	Regards
		Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0tH1buJ1a+1Sn8oRArNFAKDkTCKOxrcsheTmWVpcRyFhDY+H+QCdEt+O
7sBLA1aO2QAsmfIbA3OAQJ8=LeBA
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Greg KH]

On Fri, Jun 18, 2004 at 10:12:33AM +0200, Hannes Reinecke wrote:
> Oliver Neukum wrote:
> >Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
> >
> >>>On Thu, Jun 17, 2004 at 03:22:07PM -0500, linas@austin.ibm.com wrote:
> >>>
> >>>>By contrast, I can't see what's architecturally unclean about 
> >>>>having device drivers make the call as to when they think they
> >>>>are finally up and ready to go, e.g. by making one puny subroutine 
> >>>>call at the end of thier init sequence.  Why would this be a bad idea?
> >>>
> >>>Because it would be a major architecture change in the middle of a
> >>>stable kernel series.  I'm not going to agree to do that at this time.
> >
> >
> >If you are willing to use a model of a blocking counter you can confine
> >the changes to just the actual hotplug generation. The change is well
> >encapsuled. Drivers not caring about the block/unblock affair simply get
> >the old behavior.
> >It's less elegant than waiting for the specific files, but workable.
> >
> You mean add an additional sysfs attribute which serves as an checkpoint 
> (i.e. if this attribute exists, the initialisation is done)?

That is what udev does today.  No kernel changes are needed to implement
this.

> Neat. Fixing the drivers (or even adding another generic function to 
> drivers/base/core.c) should be pretty straightforward.
> One could even add another ENV which contains the name of the checkpoint 
> attribute; this way it's pretty clear to any script whether it needs to 
> wait or not.

Yeah, we could add this to the drivers if you really need to, but again,
userspace can do it just as easily.

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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: Delayed hotplug events

[Oliver Neukum]

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

Am Samstag, 19. Juni 2004 02:07 schrieb Greg KH:
> > You mean add an additional sysfs attribute which serves as an checkpoint 
> > (i.e. if this attribute exists, the initialisation is done)?
> 
> That is what udev does today.  No kernel changes are needed to implement
> this.

True, but it doesn't solve the basic problem. You'll never know whether
you have to wait a little longer or you should give up. You'll have
heuristics, but you'll never _know_.

	Regards
		Oliver

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

iD8DBQFA0/ZfbuJ1a+1Sn8oRAnQkAKDrYnBEWI3raIF2IHRfJlvvhBrr0gCfXH2m
vTUPPNpju5vJdzIZpolTKcA=QMvr
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
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