Delayed hotplug events
Subsystems (3)
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
Signature · 4 lines
Dr. Hannes Reinecke [email protected] SuSE Linux AG S390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de
lib/kobject.c renamed from lib/kobject.c.orig +49 -0
@@ -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 renamed from drivers/base/core.c.orig +21 -0
@@ -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 renamed from drivers/scsi/scsi_sysfs.c.orig +3 -0
@@ -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 renamed from include/linux/kobject.h.orig +3 -0
@@ -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 renamed from include/linux/device.h.orig +2 -0
@@ -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 */
Quoted 7 lines · Hannes Reinecke
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 :)
Quoted 4 lines
This is due to the design of the driver core:
a call todevice_registerwill 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.
Quoted 7 lines
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.
Quoted 6 lines
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 :)
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Donnerstag, 17. Juni 2004 20:09 schrieb Greg KH:
Quoted 4 lines
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Oliver Neukum
Am Donnerstag, 17. Juni 2004 20:09 schrieb Greg KH:
Quoted 4 lines
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Greg KH
Quoted 5 lines · Hannes Reinecke
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.
Quoted 8 lines
Quoted 1 line
Is this approach feasible or am I completely off kilter here?
Off kilter :)
Quoted 1 line
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&m8034761409426&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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 12 lines · Patrick Mansfield
Quoted 11 lines · Greg KH
Quoted 6 lines · Hannes Reinecke
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 :)
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Oliver Neukum
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Am Donnerstag, 17. Juni 2004 20:09 schrieb Greg KH:
Quoted 2 lines
Quoted 1 line
And if the latter, how should it be solved properly?
Quoted 7 lines
Quoted 2 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · On Thu, Jun 17, 2004 at 03:22:07PM -0500, [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
Quoted 9 lines · On Thu, Jun 17, 2004 at 03:22:07PM -0500, [email protected] wrote:
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 13 lines · Oliver Neukum
Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
Quoted 9 lines
Quoted 9 lines · On Thu, Jun 17, 2004 at 03:22:07PM -0500, [email protected] wrote:
Quoted 5 lines
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.
Quoted 6 lines
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
Signature · 15 lines
Dr. Hannes Reinecke [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Freitag, 18. Juni 2004 10:12 schrieb Hannes Reinecke:
Quoted 14 lines
Quoted 13 lines · Oliver Neukum
Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
Quoted 9 lines
Quoted 9 lines · On Thu, Jun 17, 2004 at 03:22:07PM -0500, [email protected] wrote:
Quoted 5 lines
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.
Quoted 8 lines
Quoted 6 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Oliver Neukum
Am Freitag, 18. Juni 2004 10:12 schrieb Hannes Reinecke:
Quoted 2 lines
Quoted 2 lines
Oliver Neukum wrote:
[ .. ]
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
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
Signature · 15 lines
Dr. Hannes Reinecke [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 8 lines
Quoted 4 lines
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.
Quoted 4 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 14 lines · Hannes Reinecke
Quoted 13 lines · Oliver Neukum
Am Freitag, 18. Juni 2004 01:57 schrieb Greg KH:
Quoted 9 lines
Quoted 9 lines · On Thu, Jun 17, 2004 at 03:22:07PM -0500, [email protected] wrote:
Quoted 5 lines
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.
Quoted 8 lines
Quoted 6 lines
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.
Quoted 5 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Samstag, 19. Juni 2004 02:07 schrieb Greg KH:
Quoted 5 lines
Quoted 2 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel