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
On Apr 21, 2009, at 1:35 PM, Trond Myklebust wrote:
On Tue, 2009-04-21 at 10:48 -0400, Christoph Hellwig wrote:
On Mon, Apr 20, 2009 at 09:17:23PM +0530, Suresh Jayaraman wrote:
+static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
+struct file
> > 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, 2009-04-21 at 10:48 -0400, Christoph Hellwig wrote:
> On Mon, Apr 20, 2009 at 09:17:23PM +0530, Suresh Jayaraman wrote:
> > +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
> > +struct file *filp, loff_t *ppos,
> > +
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
On Mon, Apr 20, 2009 at 09:17:23PM +0530, Suresh Jayaraman wrote:
> +static ssize_t nfs_file_splice_write(struct pipe_inode_info *pipe,
> + struct file *filp, loff_t *ppos,
> + size_t count, unsigned int flags)
> +{
> + struct de
> +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
24 matches
Mail list logo
