On 8/10/07, Javier Pello <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
