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

[Kay Sievers]

On 8/10/07, Javier Pello <javier.pello@xxxxxxx> wrote:
> On Thu 09 Aug 2007, Kay Sievers wrote:
>
> > On Thu, 2007-08-09 at 11:36 +0200, Javier Pello wrote:
> >
> > > Anyway, my point is that it is useless to have the kernel block for
> > > a minute at boot waiting for something that cannot happen, and that
> > > it should be avoided (even if my proposed solution is not the way
> > > to go).
> >
> > That's true. And it sounds all reasonable from your point of view,
> > and the firmware loader needs fixing, and the silly blocking request
> > needs to be removed from the kernel, that's known for a very long
> > time now, but nobody did the work so far.
>
> If I see it correctly, your point is that the firmware loader is
> totally broken and needs replacing. That's fine, and I won't say
> otherwise. But it doesn't seem that such replacement is under way
> and, in the meanwhile, we are stuck with what we have. I'm not
> defending the current loader but, while we have it, we might as
> well not have it freeze the whole kernel for a minute waiting
> for something that won't happen.
>
> > But in this specific case, it is more the combination of your
> > options, what causes this problem to appear. You don't have an
> > initramfs, you don't use modules, but you are linking a driver
> > into the kernel image which depends on a conceptually broken
> > blocking userspace transaction to initialize.
> > This combination of options just doesn't make sense. Either
> > use initramfs, or use a kernel module for the driver that needs
> > userspace to initialize, or patch the driver not to block in
> > the request, or patch the driver to optionally include the
> > firmware in the driver.
>
> Note that the problem is not getting the driver to work---I can
> do that pretty easily. The problem is that there's a number of
> drivers that, just because they require firmware, will hang the
> kernel on boot if built in unless an initramfs is carefully
> prepared. An allyesconfig kernel could freeze for 10 minutes
> during boot just because it came across 10 devices requiring
> firmware, even if you don't intend to use them.
>
> > You just picked a set of options that doesn't work nicely
> > together.
>
> I agree. That's why I sent the patch, to make it work better.
>
> > No distro setup has this problem, that's probably why nobody
> > really cared and it didn't get fixed so far.
>
> I agree again. But the fact that it didn't get fixed so far
> doesn't mean that it can never get fixed, does it?
>
> Also, note that I'm not proposing massive changes, or changes
> that will break things for other people (not intentionally,
> anyway), or that will add complexity and unmaintainability
> to the kernel. They try to do a reasonable thing and are
> small and to the point.

Sure, but all these problems don't happen, if you don't include an
"incomplete" driver in the kernel image.
What I want to say is that it seems obvious to me to compile a driver,
which depends on a userspace transaction, as a module. Even with your
changes, compiling it in still depends on a weird userspace rebinding
hack to make it work, which doesn't solve the problem at a generic
level, where it should be fixed instead.

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