Re: Wait for console to become available, v3.2

[David VomLehn]

On Sat, Apr 25, 2009 at 02:41:52AM +0100, Jamie Lokier wrote:
> David VomLehn wrote:
> > I think this is over-engineered. This focused on boot devices, so you really
> > don't care about things like buses, and I don't perceive a broader use. What
> > really matters is particular boot device types, wherever they came from.
> 
> I'm thinking this broader use:
> 
>     - My boot _script_ is waiting for a disk which identifies as
>       UUID=392852908752345749857 to appear before it can mount it on
>       /data.  If there's no such disk, it proceeds without it.  It's a
>       USB disk, behind a USB hub.
> 
>     - My boot script is looking to see if I'm holding down 'z' on the
>       keyboard, to do something different.  But how does it know if
>       there's a USB keyboard plugged in (behind two USB hubs) that
>       hasn't finished being detected?
> 
> It just seemed to fit comfortably into what's being discussed.
> 
> (I do have these a system with these requirements, by the way.  It's
> solved at the moment by waiting 5 seconds after booting, and by using
> an older kernel which doesn't have boot parallelisation yet...)

If the keyboard is being used for the console, this should fix your problem.
If not, I think you can fix it by using a hotplug script.

> Only one problem I see: what happens when there's an attempt to open
> /dev/console before you increment the pending count?  It seems to me
> you have to wait for all buses to have been detected, which is why I
> mentioned buses, as some buses are _themselves_ slow devices to detect.

A valid point. I just sent an updated patch to address this.

> > The key question is, are there cases where there is enough time between steps
> > 1 and 2, and steps 2 and 3, to add this complexity? If not, let's skip it.
> 
> The time between enumerating that a USB device exists and what it's
> class is (could be a console?), and actually initialising the device
> to find out if it's then usable, including loading firmware, can be a
> little while.
> 
> I don't know if the times are long enough to matter.

Me neither, but I went ahead and added bus_bootdev_type_found. It's a trivial
piece of code and will allow this case to be handled cleanly.

> Possibly related to all this: it would be really nice if the ATA
> rather slow probe time didn't have to delay boot scripts until they
> depend on the not-yet-probed disks, as sometimes they might not.

Related to boot time, yes, but it sounds like it's not related to the
boot device issue. By the time you get to boot scripts, you've initialized
all the boot devices you're going to.

> -- Jamie

David VomLehn
--
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/