Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence

[Pierre Ossman <drzeus@drzeus.cx>]

Haavard Skinnemoen wrote:
> On Thu, 10 May 2007 17:58:27 +0200
> Pierre Ossman <drzeus@drzeus.cx> wrote:
> 
> 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?
> 

You're assuming two things:

1. The bus the host controller reside on is synchronous both in adding devices
and drivers. This is true for most buses, but not all. As we can see, the MMC
bus is an example of one that isn't.

2. The bus the host controller reside on is scanned before any sync function we add.

The second probably isn't much of a stretch, but the first is more likely to
break. E.g. an usb based controller would not satisfy 1 as usb is scanned
asynchronously. Platform devices are case by case (e.g. some device might be
delayed since it needs time to power up).

>> 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"?
> 

It isn't. The MMC bus is a pesky bugger in that it is slow and involves a lot of
sleeping and asynchronous callbacks. As such, synchronisation needs to be very
explicit using for example completions.

>>> 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.
> 

Probably. But I'd like to hope we're gaining more than we lose. There are some
horror stories from the scsi camp where synchronous scanning means it takes an
hour to boot a machine.

>> 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...
> 

I'm not familiar with that code, but I would guess it has a whole bunch of
prerequisite conditions. And the nfs root installations I've seen all use
initrd, so I would assume there are some restrictions to letting the kernel
handle it.

>> 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.
> 

I think most people can live with having an initrd, so I wouldn't paint quite
such a bleak picture.

> Btw, how can I wait for the scanning to complete from early userspace?
> 

Monitor /proc/partitions or /sys until the device you need for rootfs shows up.


The big problem from my point of view is that I do not want to start promising
people a feature we might not be able to support in the future, and perhaps not
even now with some hardware.

Is there some reason you cannot use an initrd or is it just the inconvenience?


Rgds
Pierre

Attachment: signature.asc
Description: OpenPGP digital signature