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

2009-04-26 Thread Jamie Lokier
Alan Stern wrote: On Sat, 25 Apr 2009, Jamie Lokier wrote: 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

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

2009-04-26 Thread Jamie Lokier
Alan Stern wrote: On Sun, 26 Apr 2009, Jamie Lokier wrote: Are you suggesting this new interface be exported to userspace somehow? Not directly. Only in the same way that open(/dev/console) delays until there's a console, so reading the keyboard can delay until we know if we had a

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

2009-04-26 Thread Kay Sievers
On Sun, Apr 26, 2009 at 23:37, Jamie Lokier ja...@shareable.org wrote: Alan Stern wrote: As for searching for a particular UUID, I believe recent changes to sysfs/udev should improve the situation.  There will be a by_UUID directory somewhere, containing a bunch of symbolic links whose names

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

2009-04-26 Thread Jamie Lokier
Kay Sievers wrote: _If_ the system doesn't wait for all block devices present at boot to be enumerated before the boot script, then when the script looks in that directory for a specific UUID, it would be good to wait until has everything present at boot been enumerated? says yes.

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

2009-04-26 Thread Kay Sievers
On Mon, Apr 27, 2009 at 01:12, Jamie Lokier ja...@shareable.org wrote: Kay Sievers wrote: _If_ the system doesn't wait for all block devices present at boot to be enumerated before the boot script, then when the script looks in that directory for a specific UUID, it would be good to wait

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

2009-04-26 Thread Jamie Lokier
Kay Sievers wrote: On Mon, Apr 27, 2009 at 01:12, Jamie Lokier ja...@shareable.org wrote: Kay Sievers wrote: _If_ the system doesn't wait for all block devices present at boot to be enumerated before the boot script, then when the script looks in that directory for a specific UUID, it

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

2009-04-24 Thread Alan Stern
On Thu, 23 Apr 2009, David VomLehn wrote: I'm still scratching my head, trying to figure out where I can tap into the 'USB notion of all devices that were present at boot time have been probed' that Alan mentions above, so I don't have a specific implementation yet. I'm open to any tips in

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

2009-04-24 Thread David VomLehn
On Fri, Apr 24, 2009 at 03:20:42PM -0400, Alan Stern wrote: On Thu, 23 Apr 2009, David VomLehn wrote: I'm still scratching my head, trying to figure out where I can tap into the 'USB notion of all devices that were present at boot time have been probed' that Alan mentions above, so I

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

2009-04-24 Thread Jamie Lokier
David VomLehn wrote: This looks like a good plan and not hard to implement. It even should be possible to fit USB disk drives into the scheme. That would definitely rock. How about this, perhaps in the generic device model: 1. Whenever a device's existence is detected by its parent

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

2009-04-24 Thread David VomLehn
On Fri, Apr 24, 2009 at 11:19:51PM +0100, Jamie Lokier wrote: David VomLehn wrote: This looks like a good plan and not hard to implement. It even should be possible to fit USB disk drives into the scheme. That would definitely rock. How about this, perhaps in the generic device

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

2009-04-24 Thread Jamie Lokier
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

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

2009-04-23 Thread David VomLehn
On Wed, Apr 22, 2009 at 05:24:18PM -0400, Alan Stern wrote: On Wed, 22 Apr 2009, Alan Cox wrote: 2.All devices have been probed If we exit for reason 2, it means that no such device is present, and we go on to the do the appropriate thing for that device class. USB has no

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

2009-04-22 Thread Jamie Lokier
Alan Cox wrote: To start with there is no reason that the USB console can't implement a maybe we have hardware, maybe I buffer 64K until it shows up behaviour and bind to hardware as and when USB serial devices get inserted. Ah, that doesn't work, when you want to use the USB serial console

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

2009-04-22 Thread Jamie Lokier
Linus Torvalds wrote: [ Actually, looking closer we should not use that particular name: we already have something called a console_driver which is really the current VT driver. Speaking of names... The word console is used to mean three different things in the kernel. Last time I had

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

2009-04-22 Thread Alan Cox
Ah, that doesn't work, when you want to use the USB serial console _if_ there's a USB serial adapter plugged in, and a different (lower priority) console if it's not. I don't see the problem. If there is a lower priority console available then the kernel can use that anyway and clearly that

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

2009-04-22 Thread Jamie Lokier
Alan Cox wrote: It would be a sensible though boring cleanup to change all the VC (virtual console) stuff to use the name VT (virtual terminal) consistently. Then we would have two completely different meanings for virtual terminal in the kernel. As opposed to three meanings for console

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

2009-04-22 Thread Alan Stern
On Tue, 21 Apr 2009, David VomLehn wrote: The current patch already uses a waitqueue and wakes up as soon as a console is registered, so that's the same. I agree that the other piece is determining when all USB devices at boot time have been probed. For this suggestion to work, two conditions

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

2009-04-22 Thread David VomLehn
On Wed, Apr 22, 2009 at 11:40:09AM -0400, Alan Stern wrote: On Tue, 21 Apr 2009, David VomLehn wrote: ... There is one other possible gotcha to this approach. The code as I wrote it is bus-agnostic, i.e. it has no idea where the console is located. As far as I know, the long time to

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

2009-04-22 Thread Alan Cox
Alright, I know you (Alan (Stern)) know about USB. I think someone else mentioned Firewire. What other hotpluggable buses do we need to worry about and how can we get them interested? In theory any console can be hot pluggable - PCI-X hotplug video cards, hotplug serial ports. In fact right

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

2009-04-22 Thread Alan Stern
On Wed, 22 Apr 2009, Alan Cox wrote: 2. All devices have been probed If we exit for reason 2, it means that no such device is present, and we go on to the do the appropriate thing for that device class. USB has no notion of #2 really That's true, it doesn't. But it _does_ rather have

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

2009-04-21 Thread Ingo Molnar
* David VomLehn dvoml...@cisco.com wrote: Parallelization to improve boot times has been successful enough that race conditions now exist between the init_post() open of /dev/console and initialization of the console device. When this occurs, opening /dev/console fails and any

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

2009-04-21 Thread David Brownell
On Monday 20 April 2009, Ingo Molnar wrote: The proper approach would be to use one of the async_synchronize*() facilities in kernel/async.c to properly order the opening of the console with device init. Stepping back a moment from how to make sure what is agreed on. I think I see three

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

2009-04-21 Thread Arjan van de Ven
On Tue, 21 Apr 2009 08:43:46 +0200 Ingo Molnar mi...@elte.hu wrote: The proper approach would be to use one of the async_synchronize*() facilities in kernel/async.c to properly order the opening of the console with device init. Unfortunately this is not the answer. First of all, USB does

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

2009-04-21 Thread Ingo Molnar
* Arjan van de Ven ar...@infradead.org wrote: On Tue, 21 Apr 2009 08:43:46 +0200 Ingo Molnar mi...@elte.hu wrote: The proper approach would be to use one of the async_synchronize*() facilities in kernel/async.c to properly order the opening of the console with device init.

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

2009-04-21 Thread Alan Stern
On Tue, 21 Apr 2009, Jamie Lokier wrote: Ingo Molnar wrote: * Arjan van de Ven ar...@infradead.org wrote: But more importantly... USB *CANNOT* do this fundamental operation. USB does not have the capability to know when you have seen all devices that are connected. Devices just show

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

2009-04-21 Thread Alan Cox
+config PRINTK_CONSOLE_WAIT + int Default number of milliseconds to wait for console device + default 1000 Does this only delay init during a console-less bootup - or are there other later apps that might trigger the delay? The console proper needs to be event based not

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

2009-04-21 Thread David VomLehn
On Tue, Apr 21, 2009 at 04:26:27PM +0200, Ingo Molnar wrote: * Jamie Lokier ja...@shareable.org wrote: Ingo Molnar wrote: ... What i'm saying is: instead of wait 2000 msecs, maybe it works out hack, there should be a proper sleep+event based approach to the same. With perhaps a

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

2009-04-21 Thread David Woodhouse
On Tue, 2009-04-21 at 00:13 -0700, David Brownell wrote: Stepping back a moment from how to make sure what is agreed on. I think I see three scenarios here: - Classic PC or server, where there's a meaningful console; - Deeply embedded systems, where there isn't; - Development

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

2009-04-21 Thread David VomLehn
On Tue, Apr 21, 2009 at 06:11:11PM +0100, David Woodhouse wrote: ... The kernel output is going to be spewed when a console registers with CON_PRINTBUFFER anyway, and if we printk a warning about userspace console output being lost, that ought to be good enough to notify the user that

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

2009-04-21 Thread Linus Torvalds
On Tue, 21 Apr 2009, David Woodhouse wrote: We can provide un-hooked-up /dev/console though. Rather than just failing to open it, why can't we make __tty_open() give you a dummy tty driver which is basically equivalent to /dev/null? And then 'replace' it with the real console driver

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

2009-04-21 Thread David Woodhouse
On Tue, 2009-04-21 at 10:29 -0700, David VomLehn wrote: On Tue, Apr 21, 2009 at 06:11:11PM +0100, David Woodhouse wrote: ... The kernel output is going to be spewed when a console registers with CON_PRINTBUFFER anyway, and if we printk a warning about userspace console output being lost,

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

2009-04-21 Thread Linus Torvalds
On Tue, 21 Apr 2009, David VomLehn wrote: What in the world are users going to do when they see a message about output being lost? There is no way to recover the data and no way to prevent it in the future. I don't think this is a good approach. Sure there is. The console messages are

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

2009-04-21 Thread David VomLehn
Tue, Apr 21, 2009 at 10:37:41AM -0700, Linus Torvalds wrote: On Tue, 21 Apr 2009, David VomLehn wrote: What in the world are users going to do when they see a message about output being lost? There is no way to recover the data and no way to prevent it in the future. I don't think

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

2009-04-21 Thread Alan Stern
On Tue, 21 Apr 2009, David VomLehn wrote: If somebody would like to suggest a programming interface (a waitqueue perhaps?) by which the USB hub driver could send a notification when it becomes idle, I could implement it. I actually started the USB console stuff with exactly this

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

2009-04-21 Thread Alan Cox
failing to open it, why can't we make __tty_open() give you a dummy tty driver which is basically equivalent to /dev/null? And then 'replace' it with the real console driver if/when that later gets registered? The latter will be a high-caffeine job, but surely not impossible? This

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

2009-04-21 Thread David VomLehn
On Tue, Apr 21, 2009 at 03:09:52PM -0400, Alan Stern wrote: On Tue, 21 Apr 2009, David VomLehn wrote: If somebody would like to suggest a programming interface (a waitqueue perhaps?) by which the USB hub driver could send a notification when it becomes idle, I could implement it.

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

2009-04-21 Thread David VomLehn
On Tue, Apr 21, 2009 at 08:25:01PM +0100, Alan Cox wrote: Anybody want to try it? Just make it ignore any IO if there are no registered consoles. The patch shouldn't even be all that big, I suspect. It will work, but on its own it won't actually fix the problem people have, which is

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

2009-04-21 Thread David VomLehn
By now, pretty much everone is probably up to speed on what the USB folks are telling us: There is no way to avoid using some sort of timeout to decide whether the console is ever going to appear. So: 1. We want the minimum timeout possible so that headless systems will

Wait for console to become available, v3.2

2009-04-20 Thread David VomLehn
Parallelization to improve boot times has been successful enough that race conditions now exist between the init_post() open of /dev/console and initialization of the console device. When this occurs, opening /dev/console fails and any applications inherited from init have no standard in/out/error