Re: [PATCH] add TIMEOUT to firmware_class hotplug event
On Thu, Mar 17, 2005 at 03:34:31AM +0100, Kay Sievers wrote: > On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: > > The current implementation of the firmware class breaks a fundamental > > assumption in udevd: that the physical device can be initialised fully > > prior to executing the next event for that device. > > Here we add a TIMEOUT value to the hotplug environment of the firmware > requesting event. I will adapt udevd not to wait for anything else, if > it finds a TIMEOUT key. > > Signed-off-by: Kay Sievers <[EMAIL PROTECTED]> Applied, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add TIMEOUT to firmware_class hotplug event
On Thu, Mar 17, 2005 at 12:07:55PM +0100, Kay Sievers wrote: > On Wed, 2005-03-16 at 21:46 -0800, Greg KH wrote: > > On Thu, Mar 17, 2005 at 03:34:31AM +0100, Kay Sievers wrote: > > > On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: > > > > The current implementation of the firmware class breaks a fundamental > > > > assumption in udevd: that the physical device can be initialised fully > > > > prior to executing the next event for that device. > > > > > > Here we add a TIMEOUT value to the hotplug environment of the firmware > > > requesting event. I will adapt udevd not to wait for anything else, if > > > it finds a TIMEOUT key. > > > > Can't you just trigger off of the FIRMWARE variable instead? > > Sure, that will work too. I just thought it would be nice to give > userspace a hint about the event behavior the kernel expects, instead of > adding an exception to the udevd event management? Hm, so by adding the TIMEOUT value, we are telling userspace that we better act on this operation soon, right? That's a special case too :) Anyway, sure, this is fine, I'll go add this to the driver-bk tree. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add TIMEOUT to firmware_class hotplug event
On Wed, 2005-03-16 at 21:46 -0800, Greg KH wrote: > On Thu, Mar 17, 2005 at 03:34:31AM +0100, Kay Sievers wrote: > > On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: > > > The current implementation of the firmware class breaks a fundamental > > > assumption in udevd: that the physical device can be initialised fully > > > prior to executing the next event for that device. > > > > Here we add a TIMEOUT value to the hotplug environment of the firmware > > requesting event. I will adapt udevd not to wait for anything else, if > > it finds a TIMEOUT key. > > Can't you just trigger off of the FIRMWARE variable instead? Sure, that will work too. I just thought it would be nice to give userspace a hint about the event behavior the kernel expects, instead of adding an exception to the udevd event management? Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add TIMEOUT to firmware_class hotplug event
On Wed, 2005-03-16 at 21:46 -0800, Greg KH wrote: On Thu, Mar 17, 2005 at 03:34:31AM +0100, Kay Sievers wrote: On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: The current implementation of the firmware class breaks a fundamental assumption in udevd: that the physical device can be initialised fully prior to executing the next event for that device. Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key. Can't you just trigger off of the FIRMWARE variable instead? Sure, that will work too. I just thought it would be nice to give userspace a hint about the event behavior the kernel expects, instead of adding an exception to the udevd event management? Thanks, Kay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add TIMEOUT to firmware_class hotplug event
On Thu, Mar 17, 2005 at 12:07:55PM +0100, Kay Sievers wrote: On Wed, 2005-03-16 at 21:46 -0800, Greg KH wrote: On Thu, Mar 17, 2005 at 03:34:31AM +0100, Kay Sievers wrote: On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: The current implementation of the firmware class breaks a fundamental assumption in udevd: that the physical device can be initialised fully prior to executing the next event for that device. Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key. Can't you just trigger off of the FIRMWARE variable instead? Sure, that will work too. I just thought it would be nice to give userspace a hint about the event behavior the kernel expects, instead of adding an exception to the udevd event management? Hm, so by adding the TIMEOUT value, we are telling userspace that we better act on this operation soon, right? That's a special case too :) Anyway, sure, this is fine, I'll go add this to the driver-bk tree. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add TIMEOUT to firmware_class hotplug event
On Thu, Mar 17, 2005 at 03:34:31AM +0100, Kay Sievers wrote: On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: The current implementation of the firmware class breaks a fundamental assumption in udevd: that the physical device can be initialised fully prior to executing the next event for that device. Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key. Signed-off-by: Kay Sievers [EMAIL PROTECTED] Applied, thanks. greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add TIMEOUT to firmware_class hotplug event
On Thu, Mar 17, 2005 at 03:34:31AM +0100, Kay Sievers wrote: > On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: > > The current implementation of the firmware class breaks a fundamental > > assumption in udevd: that the physical device can be initialised fully > > prior to executing the next event for that device. > > Here we add a TIMEOUT value to the hotplug environment of the firmware > requesting event. I will adapt udevd not to wait for anything else, if > it finds a TIMEOUT key. Can't you just trigger off of the FIRMWARE variable instead? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] add TIMEOUT to firmware_class hotplug event
On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: > The current implementation of the firmware class breaks a fundamental > assumption in udevd: that the physical device can be initialised fully > prior to executing the next event for that device. Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key. Signed-off-by: Kay Sievers <[EMAIL PROTECTED]> = drivers/base/firmware_class.c 1.25 vs edited = --- 1.25/drivers/base/firmware_class.c 2004-11-26 21:26:48 +01:00 +++ edited/drivers/base/firmware_class.c2005-03-17 03:22:37 +01:00 @@ -102,6 +102,9 @@ if (add_hotplug_env_var(envp, num_envp, , buffer, buffer_size, , "FIRMWARE=%s", fw_priv->fw_id)) return -ENOMEM; + if (add_hotplug_env_var(envp, num_envp, , buffer, buffer_size, , + "TIMEOUT=%i", loading_timeout)) + return -ENOMEM; envp[i] = NULL; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] add TIMEOUT to firmware_class hotplug event
On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: The current implementation of the firmware class breaks a fundamental assumption in udevd: that the physical device can be initialised fully prior to executing the next event for that device. Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key. Signed-off-by: Kay Sievers [EMAIL PROTECTED] = drivers/base/firmware_class.c 1.25 vs edited = --- 1.25/drivers/base/firmware_class.c 2004-11-26 21:26:48 +01:00 +++ edited/drivers/base/firmware_class.c2005-03-17 03:22:37 +01:00 @@ -102,6 +102,9 @@ if (add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size, len, FIRMWARE=%s, fw_priv-fw_id)) return -ENOMEM; + if (add_hotplug_env_var(envp, num_envp, i, buffer, buffer_size, len, + TIMEOUT=%i, loading_timeout)) + return -ENOMEM; envp[i] = NULL; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add TIMEOUT to firmware_class hotplug event
On Thu, Mar 17, 2005 at 03:34:31AM +0100, Kay Sievers wrote: On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote: The current implementation of the firmware class breaks a fundamental assumption in udevd: that the physical device can be initialised fully prior to executing the next event for that device. Here we add a TIMEOUT value to the hotplug environment of the firmware requesting event. I will adapt udevd not to wait for anything else, if it finds a TIMEOUT key. Can't you just trigger off of the FIRMWARE variable instead? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
