Re: [PATCH] request_firmware: skip timeout if userspace was not notified

[Javier Pello <javier.pello@urjc.es>]

On Tue, 07 Aug 2007, Cornelia Huck wrote:

> On Tue, 7 Aug 2007 13:46:55 +0200,
> "Kay Sievers" <kay.sievers@vrfy.org> wrote:
> > How do you check if events have been "handled"? None of the recent
> > distros uses /sbin/hotplug anymore. Netlink events are broadcasted,
> > but no failure in delivery doesn't mean anything like "handled", or
> > delivered to the right instance. Even if you check that the netlink
> > socket has listeners, that wouldn't be sufficient to tell that is
> > handled.
> 
> You can't check if it's been handled, yes; but you can certainly check
> if you delivered it. I guess Javier wants to exclude the cases where
> userspace didn't have any chance to handle it.

That's right. There's no way to know if userspace does handle the event
after reception, and that's why we have a timeout (so we don't wait
forever), but we can be sure that userspace won't handle an event that
wasn't received. We want to be conservative here: if there is any
chance that the event was received, we set the timeout and wait.

> Javier: Do you have an idea how common the case "we broadcasted, but
> nobody listened so we got a timeout" is? If the usual reason for the
> timeout is that firmware was requested before a listener showed up,
> I'm not sure whether that check is worth it...

I don't know how common this is in general, but in my box it happens
(or rather happened, until I patched it) once per boot. I've got a
device that requires some firmware during initialisation. I always
build the driver into the kernel (I don't like modules for things
that are permanently attached to the computer), and that means that
it tries to initialise before the rootfs is mounted (there's no
initramfs). Before the patch, the kernel would hang for a minute
in request_firmware during each boot, which was rather annoying,
and that is the reason why I decided to fix it.

Javier


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/