[PATCH] add TIMEOUT to firmware_class hotplug event

[PATCH] add TIMEOUT to firmware_class hotplug event

[Kay Sievers]

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 <kay.sievers@vrfy.org>

===== 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.c	2005-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;
 

Re: [PATCH] add TIMEOUT to firmware_class hotplug event

[Greg KH]

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

Re: [PATCH] add TIMEOUT to firmware_class hotplug event

[Kay Sievers]

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

Re: [PATCH] add TIMEOUT to firmware_class hotplug event

[Greg KH]

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

Re: [PATCH] add TIMEOUT to firmware_class hotplug event

[Greg KH]

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 <kay.sievers@vrfy.org>

Applied, thanks.

greg k-h