Messages in this thread | | | Date | Thu, 10 May 2007 18:27:49 +0200 | From | Haavard Skinnemoen <> | Subject | Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence |
| |
On Thu, 10 May 2007 17:58:27 +0200 Pierre Ossman <drzeus@drzeus.cx> 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 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/
| |