Kay Sievers wrote:
> On Mon, Apr 27, 2009 at 01:12, Jamie Lokier 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
On Mon, Apr 27, 2009 at 01:12, Jamie Lokier 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 until
>> > "
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.
On Sun, Apr 26, 2009 at 23:37, Jamie Lokier 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
>> are the U
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
> > kno
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 keyboard plugged i
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 proceed
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,
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 it. It's a
> US
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 boo
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 gene
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 par
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 ab
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
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.
> >
>
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_ rathe
> 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
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
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 conditi
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
> 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
> 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.
Alan
--
To unsubscribe from this list: send the line "un
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
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 cons
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
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
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 impleme
> > 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?
>
> T
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
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
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 s
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
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 if
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 somet
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;
>
> - De
> 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 approach, but
switched to the approach that's out th
On Tue, Apr 21, 2009 at 04:26:27PM +0200, Ingo Molnar wrote:
>
> * Jamie Lokier 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 _time
> +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
On Tue, 21 Apr 2009, Jamie Lokier wrote:
> Ingo Molnar wrote:
> > * Arjan van de Ven 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 up a ra
* Jamie Lokier wrote:
> Ingo Molnar wrote:
> > * Arjan van de Ven 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 up a random
> > > amoun
Ingo Molnar wrote:
> * Arjan van de Ven 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 up a random
> > amount of time after you turn the power on
* Arjan van de Ven wrote:
> On Tue, 21 Apr 2009 08:43:46 +0200
> 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.
>
> Unfortunately this is not the
On Tue, 21 Apr 2009 08:43:46 +0200
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.
Unfortunately this is not the answer.
First of all, USB does not use the
* David Brownell wrote:
> 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 sur
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 thr
* David VomLehn 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 applications inherited
>
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
47 matches
Mail list logo
