On Thu, 10 May 2007 17:58:27 +0200 Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Haavard Skinnemoen wrote: > > > > Ok, is there any better way to achieve the same this? As far as I > > can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the > > same purpose -- it ensures that scans that have already been started > > will have completed before the function continues. > > > > Not quite. mmc_remove_host() doesn't care if a detect has been executed or > not, > it only cares about whether or not one is executing right now. So in order for > your patch to work, there must be no way that mmc_finish_detect() is called > before the detect is scheduled. Is there any way this can happen? Host controller drivers register themselves from module_init(), their probe() function gets called, which calls mmc_add_host(), which schedules the initial scan. If multiple host controllers are present, they will all schedule their scans before all module_init()s have been called. Am I missing something? > > I wouldn't call it luck. The way mmc_rescan() is implemented, any scans > > that are started before late_initcall time are completed before > > mmc_finish_detect() returns. The steps are all done synchronously in > > the workqueue function. > > > > Indeed. But it is not by design that they are scheduled before > late_initcall(). > Also, flushing the workqueue is also not a by-design way of completing a scan, > it just happens to be that way right now. So how is it supposed to work "by design"? > > And I never realized that using a block device as a parameter to the > > root= parameter could possibly be "unofficial" functionality...? > > Then you've learned something new. ;) Guess so. It seems like the prepare_namespace stuff is getting less useful every day. > Only some devices work that way (generally only those with "simple" > interfaces). > And most things are these days behind more advanced buses, more akin to a > network. It's funny that NFS root does not have these kinds of problems then... > Generally, not waiting for a lot of hardware is a good thing as it speeds up > boot times. In my mind, the proper way is having a script in an initrd that > waits for just the parts of the hardware that this particular system needs. > Everything else can be brought up in the background. Yeah, but I suspect most users will rather have a system that actually boots than a system that would have booted very quickly if it had booted at all. Btw, how can I wait for the scanning to complete from early userspace? Haavard - 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/
