* Re: Wait for console to become available, v3.2
From: David Woodhouse @ 2009-04-21 17:41 UTC (permalink / raw)
To: David VomLehn
Cc: David Brownell, alan-qBU/x9rampVanCEyBjwyrvXRex20P6io,
Ingo Molnar, Arjan van de Ven, H. Peter Anvin, Thomas Gleixner,
Linus Torvalds, Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090421172929.GC8251-CFZJ1or75eBPWxJt6d6B6bQa8qPdvLwY@public.gmane.org>
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, that ought to be good enough to notify the
> > user that something may have been lost. For bonus points, we could even
> > make that 'dummy' tty driver buffer a limited amount of userspace
> > output, maybe.
>
> 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.
>
> Remember, even though the previous functionality of USB consoles was, in
> theory, less reliable than it appeared, it actually has been working well
> for years. Thus, tossing output will count as a regression for most of the
> world.
So implement a small amount of buffering, as I suggested, and it should
be sufficient to cover the cases that were only working before by blind
luck anyway.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Linus Torvalds @ 2009-04-21 17:37 UTC (permalink / raw)
To: David VomLehn
Cc: David Woodhouse, David Brownell,
alan-qBU/x9rampVanCEyBjwyrvXRex20P6io, Ingo Molnar,
Arjan van de Ven, H. Peter Anvin, Thomas Gleixner,
Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090421172929.GC8251-CFZJ1or75eBPWxJt6d6B6bQa8qPdvLwY@public.gmane.org>
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 saved too, so doing 'dmesg' will
get you all the data that was generated before the console went on-line.
We _already_ lose data in that sense (although we could replay it for the
first console connected - maybe we even do, I'm too lazy to check).
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [ltt-dev] [PATCH] nfs: add support for splice writes
From: Trond Myklebust @ 2009-04-21 17:35 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Suresh Jayaraman, Masahiro Tamori, Mathieu Desnoyers,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
ltt-dev-33AaDErTWvBVxDZ2/Zk0YoryAYyacSEB, LKML,
linux-embedded-u79uwXL29TY76Z2rM5mHXA, Peter Zijlstra
In-Reply-To: <20090421144810.GA7036-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
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,
> > + size_t count, unsigned int flags)
> > +{
> > + struct dentry *dentry = filp->f_path.dentry;
> > +
> > + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
> > + dentry->d_parent->d_name.name, dentry->d_name.name,
> > + (unsigned long) count, (unsigned long long) *ppos);
> > +
> > + return generic_file_splice_write(pipe, filp, ppos, count, flags);
> > +}
> > +
>
> You need all calls from nfs_file_write, too:
>
> - most importantly the nfs_revalidate_file_size for O_APPEND
Isn't O_APPEND illegal for splice_write()? It looks like it is from a
quick perusal of do_splice_from().
> - the nfs_do_fsync for sync writes
generic_file_splice_write() calls generic_osync_inode(), which should
ensure sync writes even with NFS.
The one thing it won't do is propagate NFS write errors back to the
caller. If we do care about this, then we should certainly test for
nfs_need_sync_write() and then call nfs_do_fsync() (see
nfs_file_write()).
> - probably the stats increment
We should talk to Chuck about this.
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Linus Torvalds @ 2009-04-21 17:31 UTC (permalink / raw)
To: David Woodhouse
Cc: David Brownell, alan, Ingo Molnar, David VomLehn,
Arjan van de Ven, H. Peter Anvin, Thomas Gleixner,
Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <1240333871.3632.70.camel@macbook.infradead.org>
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/when that later gets registered? The
> latter will be a high-caffeine job, but surely not impossible?
This sounds like a good option.
Right now we look through all the console_drivers at open time in that
struct tty_driver *console_device(int *index)
thing, but it should be possible to just do something like
static struct tty_driver console_driver;
and then just make "console_device()" always return _that_ tty driver
instead. Then, we could make that console_device tty driver just at
run-time spread the IO to the proper device(s), rather than fix the one
particular device at "open()" time.
[ 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.
So we should call it 'system_console_device' or something, but you
get the idea. ]
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.
Linus
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: David VomLehn @ 2009-04-21 17:29 UTC (permalink / raw)
To: David Woodhouse
Cc: David Brownell, alan, Ingo Molnar, Arjan van de Ven,
H. Peter Anvin, Thomas Gleixner, Linus Torvalds,
Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <1240333871.3632.70.camel@macbook.infradead.org>
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 something may have been lost. For bonus points, we could even
> make that 'dummy' tty driver buffer a limited amount of userspace
> output, maybe.
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.
Remember, even though the previous functionality of USB consoles was, in
theory, less reliable than it appeared, it actually has been working well
for years. Thus, tossing output will count as a regression for most of the
world.
> If userspace cares, let _it_ wait, by using an ioctl to see what tty
> device it's _really_ attached to.
I have a notion, perhaps misguided, that userspace *always* cares about
seeing all the output they have generated.
I have no objection to a userspace solution, in the long run, but such an
approach represents a significantly different approach to constructing boot
filesystems and we need a transitional period. In the interim, let's get
things working as they were.
> David Woodhouse Open Source Technology Centre
David VomLehn
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: David Woodhouse @ 2009-04-21 17:11 UTC (permalink / raw)
To: David Brownell, alan
Cc: Ingo Molnar, David VomLehn, Arjan van de Ven, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
Linux USB Mailing List, Linux Embedded Mailing List,
Andrew Morton
In-Reply-To: <200904210013.48551.david-b@pacbell.net>
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 stages of "deeply embedded", where there *may* be one.
>
> If that's correct, then async_synchronize() isn't a full answer...
>
> I think a fair number of cases can be papered over with a serial
> console with no hardware flow control, which isn't hooked up to
> anything. Maybe the board needs a test/development jig to get one;
> without it, the "console" bits spill out into the aether. Linux
> can dump bits to ttyS0, which will act like /dev/null.
>
> But the problem case here seems to be one where such un-hooked-up
> serial ports are not realistic options. Which is why the regression
> in USB console functionality has been troublesome.
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/when that later gets registered? The
latter will be a high-caffeine job, but surely not impossible?
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 something may have been lost. For bonus points, we could even
make that 'dummy' tty driver buffer a limited amount of userspace
output, maybe.
If userspace cares, let _it_ wait, by using an ioctl to see what tty
device it's _really_ attached to.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: David VomLehn @ 2009-04-21 16:52 UTC (permalink / raw)
To: Alan Stern
Cc: Jamie Lokier, Ingo Molnar, Arjan van de Ven, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
Linux USB Mailing List, Linux Embedded Mailing List,
Andrew Morton
In-Reply-To: <Pine.LNX.4.44L0.0904211026080.2981-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
> 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 there. A minor drawback, which is
probably obvious, is that you actually wait for some interval without
getting anything to do before you think things are idle. But a bigger
drawback is that you lose the ability to chose appropriate intervals for
different classes of devices.
So far, there appear to be three possible USB boot devices: consoles, network
devices, and boot devices. A system may not have all of these and so may not
need to wait as long as a system with all of them. One of my goals is to
preserve as much of the reduction in boot time as possible, even on systems
that use USB devices that may or may not be plugged in.
> Alan Stern
David VomLehn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: David VomLehn @ 2009-04-21 16:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jamie Lokier, Arjan van de Ven, H. Peter Anvin, Thomas Gleixner,
Linus Torvalds, Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090421142627.GA18129@elte.hu>
On Tue, Apr 21, 2009 at 04:26:27PM +0200, Ingo Molnar wrote:
>
> * Jamie Lokier <jamie@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 _timeout_ for the "no console
> > > arrived" negative case as well. (which timeout can be set to
> > > zero in the "I _know_ there's no console around".)
> >
> > Isn't the proposed code doing exactly that? It sleeps waiting for
> > a console, with a timeout of X msecs. If a console arrives before
> > that, doesn't it wake immediately?
>
> Yes - except that the timeout is aspecific. I.e. we'll time out even
> if the delay happens not due to a device arriving too late (or not
> arriving at all), but due to some earlier init step taking an
> unexpectedly long time.
I agree, but this is also a pretty good description of why things actually
worked before--it just so happened that work intervening between starting
USB enumeration and the opening of /dev/console was long enough that
USB serial devices were initialized. So, no, it's not good. But it's a
pretty close equivalent to previous behavior.
That being said, I'm also thinking that the timeout interval should start when
bus initialization is started. The point between the start of USB
initialization and when a particular device is initialized should be, as
a practical matter and for a particular hardware configuration, more or
less constant, and so more predictable for users.
Basing the wait interval from the start of bus initialization has the
additional advantage that we can also implement similar timers, such as one
for network devices, off the same base time. Since the ip= kernel parameter
is similarly broken, I've been looking at what it would take to get it
working again, too. Or at least, with deference to the constraints of USB and
acknowledging the importance of luck, working as well as it used to.
> Also, if we end up doing this - the patch, as proposed right now,
> appears to add a default 1000 msecs sleep to every __tty_open()
> call:
>
> +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?
Sleeping and polling for an event, rather than using a suitable notification
primitive, causes me existential anguish. Seriously, I *hate* code like that
and systems that make you do such brutish things. Linux is not one of those
throwbacks, so as soon as a console shows up, we continue. Thus, we only wait
the whole interval if the console device is very slow to initialize or if
there is no console device, at all.
--
David VomLehn
^ permalink raw reply
* Re: [ltt-dev] [PATCH] nfs: add support for splice writes
From: Christoph Hellwig @ 2009-04-21 14:48 UTC (permalink / raw)
To: Suresh Jayaraman
Cc: Trond Myklebust, Masahiro Tamori, Mathieu Desnoyers, linux-nfs,
ltt-dev, LKML, linux-embedded, Peter Zijlstra
In-Reply-To: <49EC990B.1030007@suse.de>
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 dentry *dentry = filp->f_path.dentry;
> +
> + dprintk("NFS splice_write(%s/%s, %lu@%Lu)\n",
> + dentry->d_parent->d_name.name, dentry->d_name.name,
> + (unsigned long) count, (unsigned long long) *ppos);
> +
> + return generic_file_splice_write(pipe, filp, ppos, count, flags);
> +}
> +
You need all calls from nfs_file_write, too:
- most importantly the nfs_revalidate_file_size for O_APPEND
- the nfs_do_fsync for sync writes
- probably the stats increment
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Alan Cox @ 2009-04-21 14:37 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jamie Lokier, Arjan van de Ven, David VomLehn, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
Linux USB Mailing List, Linux Embedded Mailing List,
Andrew Morton
In-Reply-To: <20090421142627.GA18129-X9Un+BFzKDI@public.gmane.org>
> +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 timeout hacks. Can we
please fix this stuff properly ? 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. We do much of this for the VT drivers so we save
messages before PCI and fb come up.
The timeout wait proposed is also wrong I agree. Take a timestamp at the
point we are ready to mount the root fs, any delays on root mount, console
appearance etc should then be tested against this timestamp not as delays
versus some undefined later event.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Alan Stern @ 2009-04-21 14:36 UTC (permalink / raw)
To: Jamie Lokier
Cc: Ingo Molnar, Arjan van de Ven, David VomLehn, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, Linux Kernel Mailing List,
Linux USB Mailing List, Linux Embedded Mailing List,
Andrew Morton
In-Reply-To: <20090421140533.GA6375@shareable.org>
On Tue, 21 Apr 2009, Jamie Lokier wrote:
> Ingo Molnar wrote:
> > * Arjan van de Ven <arjan@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 up a random
> > > amount of time after you turn the power on for the bus.... there's
> > > no "and now we've seen all" operation.
> >
> > Yes - and this is fundamentally true of any hotplug bus design.
>
> It's not fundamental, for devices you know are plugged in at boot.
> All it takes is for the bus to support a synchronous "enumerate all"
> procedure. That _could_ involve a timeout, but there are better ways.
> But not for USB.
Is that last sentence necessarily true? I suppose it is true that a
USB device isn't obligated to make its presence on the bus known
immediately, but nevertheless, most of them do. In theory we could add
code to the USB subsystem to detect when the hub driver has become idle
and therefore all devices that were initially plugged in have been
probed.
That probably would work for solving the console problem. Storage
devices present additional problems, however:
When usb-storage discovers a device, it generally delays a while before
scanning it. (The default delay is 5 seconds, but it is adjustable by
a module parameter.) And then when the scanning function is called,
the SCSI subsystem turns it into an asynchronous request -- that's why
the kernel log usually says "usb-storage: device scan complete" before
the scan has in fact begun.
So I don't know about determining when all USB mass-storage devices
have been detected, but USB serial devices should be practical.
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.
Alan Stern
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Ingo Molnar @ 2009-04-21 14:26 UTC (permalink / raw)
To: Jamie Lokier
Cc: Arjan van de Ven, David VomLehn, H. Peter Anvin, Thomas Gleixner,
Linus Torvalds, Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090421140533.GA6375@shareable.org>
* Jamie Lokier <jamie@shareable.org> wrote:
> Ingo Molnar wrote:
> > * Arjan van de Ven <arjan@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 up a random
> > > amount of time after you turn the power on for the bus.... there's
> > > no "and now we've seen all" operation.
> >
> > Yes - and this is fundamentally true of any hotplug bus design.
>
> It's not fundamental, for devices you know are plugged in at boot.
> All it takes is for the bus to support a synchronous "enumerate
> all" procedure. That _could_ involve a timeout, but there are
> better ways. But not for USB.
>
> > 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 _timeout_ for the "no console
> > arrived" negative case as well. (which timeout can be set to
> > zero in the "I _know_ there's no console around".)
>
> Isn't the proposed code doing exactly that? It sleeps waiting for
> a console, with a timeout of X msecs. If a console arrives before
> that, doesn't it wake immediately?
Yes - except that the timeout is aspecific. I.e. we'll time out even
if the delay happens not due to a device arriving too late (or not
arriving at all), but due to some earlier init step taking an
unexpectedly long time.
> > Do you see the fundamental design difference between the two
> > solutions?
>
> The only difference I see is: If you asked for a USB console, the
> timeout should begin relative to when the USB host driver kicks
> the bus, not the first /dev/console open.
>
> Conceptually the timeout is a USB characteristic, not a generic
> console one.
>
> For other (non-USB) devices which might take a while to
> initialise, it should work as you describe. E.g. an ethernet TCP
> console should register ("i'm trying to give you a console")
> followed by ("got it") or ("failed, carry on without me").
I guess we could live with this one too but still it feels wrong to
me. It would be much better to push the decision to time out into
individual console drivers.
Also, if we end up doing this - the patch, as proposed right now,
appears to add a default 1000 msecs sleep to every __tty_open()
call:
+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?
Ingo
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Jamie Lokier @ 2009-04-21 14:05 UTC (permalink / raw)
To: Ingo Molnar
Cc: Arjan van de Ven, David VomLehn, H. Peter Anvin, Thomas Gleixner,
Linus Torvalds, Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090421135034.GA30114-X9Un+BFzKDI@public.gmane.org>
Ingo Molnar wrote:
> * Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.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 up a random
> > amount of time after you turn the power on for the bus.... there's
> > no "and now we've seen all" operation.
>
> Yes - and this is fundamentally true of any hotplug bus design.
It's not fundamental, for devices you know are plugged in at boot.
All it takes is for the bus to support a synchronous "enumerate all"
procedure. That _could_ involve a timeout, but there are better ways.
But not for USB.
> 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 _timeout_ for the "no console arrived" negative
> case as well. (which timeout can be set to zero in the "I _know_
> there's no console around".)
Isn't the proposed code doing exactly that? It sleeps waiting for a
console, with a timeout of X msecs. If a console arrives before that,
doesn't it wake immediately?
> Do you see the fundamental design difference between the two
> solutions?
The only difference I see is: If you asked for a USB console, the
timeout should begin relative to when the USB host driver kicks the
bus, not the first /dev/console open.
Conceptually the timeout is a USB characteristic, not a generic
console one.
For other (non-USB) devices which might take a while to initialise, it
should work as you describe. E.g. an ethernet TCP console should
register ("i'm trying to give you a console") followed by ("got it")
or ("failed, carry on without me").
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Ingo Molnar @ 2009-04-21 13:50 UTC (permalink / raw)
To: Arjan van de Ven
Cc: David VomLehn, H. Peter Anvin, Thomas Gleixner, Linus Torvalds,
Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090421063549.3b71881d-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
* Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> On Tue, 21 Apr 2009 08:43:46 +0200
> Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org> 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 async_* infrastructure, so it does
> not do anything.
[ Of course it does not. Two kernel cycles ago nothing had any async
infrastructure ;-) We barely have any use of it today. But cases
like this are the way to extend its use. ]
> 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 for the bus.... there's
> no "and now we've seen all" operation.
Yes - and this is fundamentally true of any hotplug bus design.
Nevertheless the wish has been expressed to wait for such a device
to become available, in this very thread we are discussing.
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 _timeout_ for the "no console arrived" negative
case as well. (which timeout can be set to zero in the "I _know_
there's no console around".)
Do you see the fundamental design difference between the two
solutions?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Arjan van de Ven @ 2009-04-21 13:35 UTC (permalink / raw)
To: Ingo Molnar
Cc: David VomLehn, H. Peter Anvin, Thomas Gleixner, Linus Torvalds,
Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090421064346.GB8020@elte.hu>
On Tue, 21 Apr 2009 08:43:46 +0200
Ingo Molnar <mingo@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 not use the async_* infrastructure, so it does
not do anything.
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 for the bus.... there's no "and now we've seen
all" operation.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Ingo Molnar @ 2009-04-21 8:03 UTC (permalink / raw)
To: David Brownell
Cc: David VomLehn, Arjan van de Ven, H. Peter Anvin, Thomas Gleixner,
Linus Torvalds, Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <200904210013.48551.david-b@pacbell.net>
* David Brownell <david-b@pacbell.net> 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 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 stages of "deeply embedded", where there *may* be
> one.
>
> If that's correct, then async_synchronize() isn't a full answer...
>
> I think a fair number of cases can be papered over with a serial
> console with no hardware flow control, which isn't hooked up to
> anything. Maybe the board needs a test/development jig to get
> one; without it, the "console" bits spill out into the aether.
> Linux can dump bits to ttyS0, which will act like /dev/null.
>
> But the problem case here seems to be one where such un-hooked-up
> serial ports are not realistic options. Which is why the
> regression in USB console functionality has been troublesome.
>
> Is that correct?
Not sure i understand the complication.
The practical issue addressed by this particular patch i've replied
to is that if /dev/console is sys_open()-ed by an app "too early",
an error code is returned and subsequently user-space (and all its
child tasks) remain console-less.
Whether the console has flow control or not is immaterial.
Initialization sequence ordering details should be transparent as
far as sys_open() of a console is concerned.
If there is _no console_, then obviously there's nothing to wait for
and the async wait will succeed immediately. The console driver
still returns an error on sys_open() but that is expected behavior.
The solution proposed in the patch i'm replying to is a boot flag
that causes the kernel to wait N milliseconds. This is incorrect and
wrong on several levels. If the console can be initialized via a
proper handshake that should be exposed precisely - we should not
wait neither longer nor shorter than needed. _If_ there's no proper
handshake and a magic delay is needed (because there's some
hardware-internal delay needed at init time) before the console can
be used then that should be in the console driver itself and the
async-wait will wait for that automatically.
But never should we have delays like this in generic code.
Regardless of embedded versus server versus desktop issues.
Ingo
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: David Brownell @ 2009-04-21 7:13 UTC (permalink / raw)
To: Ingo Molnar
Cc: David VomLehn, Arjan van de Ven, H. Peter Anvin, Thomas Gleixner,
Linus Torvalds, Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090421064346.GB8020-X9Un+BFzKDI@public.gmane.org>
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 scenarios here:
- Classic PC or server, where there's a meaningful console;
- Deeply embedded systems, where there isn't;
- Development stages of "deeply embedded", where there *may* be one.
If that's correct, then async_synchronize() isn't a full answer...
I think a fair number of cases can be papered over with a serial
console with no hardware flow control, which isn't hooked up to
anything. Maybe the board needs a test/development jig to get one;
without it, the "console" bits spill out into the aether. Linux
can dump bits to ttyS0, which will act like /dev/null.
But the problem case here seems to be one where such un-hooked-up
serial ports are not realistic options. Which is why the regression
in USB console functionality has been troublesome.
Is that correct?
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Wait for console to become available, v3.2
From: Ingo Molnar @ 2009-04-21 6:43 UTC (permalink / raw)
To: David VomLehn, Arjan van de Ven, H. Peter Anvin, Thomas Gleixner,
Linus Torvalds
Cc: Linux Kernel Mailing List, Linux USB Mailing List,
Linux Embedded Mailing List, Andrew Morton
In-Reply-To: <20090420234006.GA1958@cuplxvomd02.corp.sa.net>
* David VomLehn <dvomlehn@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 applications inherited
> from init have no standard in/out/error devices. This is expected
> behavior if no console device is available, but quite unfortunate
> in the case where the console is just a bit slow waking up.
>
> Some buses, such as USB, offer no guarantees about how long it
> takes to discover devices, so there is no reliable way to
> distinguish between a missing console and a slow one. The
> pragmatic approach taken in this patch is to wait for a while to
> see if a console shows up, and just go on if it doesn't. The
> default delay is 1000 msec (1 second). This value is conjured out
> of thing air; any suggestions for a value that more closely
> approximates the effective delays from the olden days before USB
> consoles starting failing are more than welcome.
hm, this really seems like a bad hack and a workaround to me and as
such it is not really an acceptable solution.
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.
Certain subsystems like storage (SCSI, libata, mount code and
modules) has already been extended to this scheme.
So i think the right approach, if you want to speed up bootup, would
be to extend the same concepts to console discovery, init and open
methods.
Ingo
^ permalink raw reply
* Wait for console to become available, v3.2
From: David VomLehn @ 2009-04-20 23:40 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux USB Mailing List, Linux Embedded Mailing List,
Andrew Morton
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
devices. This is expected behavior if no console device is available, but
quite unfortunate in the case where the console is just a bit slow waking up.
Some buses, such as USB, offer no guarantees about how long it takes to
discover devices, so there is no reliable way to distinguish between a missing
console and a slow one. The pragmatic approach taken in this patch is to
wait for a while to see if a console shows up, and just go on if it doesn't.
The default delay is 1000 msec (1 second). This value is conjured out of
thing air; any suggestions for a value that more closely approximates the
effective delays from the olden days before USB consoles starting failing are
more than welcome.
There is one new command line parameters:
consoledelay=msec If msec is an integer, interpret it the maximum number
of milliseconds to wait for a preferred console device
to be registered. If it is the string "forever", wait
indefinitely for the console device. In either case
continue as soon as the console device is registered.
It could be argued that providing both a command line parameter and a Kconfig
option for the console wait time is over-engineering. There doesn't really
seem to be a reasonable way to determine a default, though, which drives the
Kconfig option. The selection of USB devices connected to the system can
only be known at runtime, which drives the need for a command line parameter.
History
v3.2 Use only a single new command line parameter by adding the possible
value "forever". Add message specifying the parameter to modify to
increase the delay for console initialization
v3.1 Correct the abbreviation for milliseconds in
Documentation/kernel-parameters.txt to be "ms", not "mS". Thanks to
Peter Anvin for this.
v3 Increase the default delay to 1 second and add kernel command line
parameters to override the default delay. Thanks to David Brownell for
his helpful suggestions.
v2 Wait for the preferred console rather than any console. Make the
delay interval a tunable.
v1 Initial version
Signed-off-by: David VomLehn <dvomlehn@cisco.com>
---
Documentation/kernel-parameters.txt | 7 +++++++
arch/mips/configs/powertv_defconfig | 2 +-
init/Kconfig | 12 ++++++++++++
kernel/printk.c | 35 +++++++++++++++++++++++++++++++++++
4 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6172e43..80a631f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -507,6 +507,13 @@ and is between 256 and 4096 characters. It is defined in the file
console=brl,ttyS0
For now, only VisioBraille is supported.
+ consoledelay=ms [KNL] If ms is an integer, wait up to ms milliseconds
+ for the preferred console to be registered, then
+ continue. Useful for systems where a console may not
+ be plugged in, such as for USB serial devices. To
+ wait indefinitely, specify the string "forever" for
+ the value of ms, i.e. consoledelay=forever.
+
coredump_filter=
[KNL] Change the default value for
/proc/<pid>/coredump_filter.
diff --git a/arch/mips/configs/powertv_defconfig b/arch/mips/configs/powertv_defconfig
index 7311e63..b4a046d 100644
--- a/arch/mips/configs/powertv_defconfig
+++ b/arch/mips/configs/powertv_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30-rc2
-# Thu Apr 16 11:29:44 2009
+# Fri Apr 17 12:38:42 2009
#
CONFIG_MIPS=y
diff --git a/init/Kconfig b/init/Kconfig
index 7be4d38..a04eba1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -835,6 +835,18 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_CONSOLE_WAIT
+ int "Default number of milliseconds to wait for console device"
+ default 1000
+ help
+ Some systems use console devices, such as USB serial devices, which
+ may not be present or which may take an unspecified amount of time
+ to be initialized. This setting is the default for the maximum number
+ of milliseconds the system will wait for a console to be registered.
+ This value can be overridden by the command line parameters
+ consolewait, to wait forever, or consoledelay=msec, to give a
+ different value for the wait.
+
config BUG
bool "BUG() support" if EMBEDDED
default y
diff --git a/kernel/printk.c b/kernel/printk.c
index 5052b54..1edc5a3 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -105,6 +105,11 @@ static unsigned log_start; /* Index into log_buf: next char to be read by syslog
static unsigned con_start; /* Index into log_buf: next char to be sent to consoles */
static unsigned log_end; /* Index into log_buf: most-recently-written-char + 1 */
+/* Definitions controlling the wait for a console device to be initialized */
+#define CONSOLE_DELAY_FOREVER (-1)
+static long console_delay = CONFIG_PRINTK_CONSOLE_WAIT; /* In milliseconds */
+static DECLARE_WAIT_QUEUE_HEAD(console_wq);
+
/*
* Array of consoles built from command line options (console=)
*/
@@ -195,6 +200,21 @@ out:
__setup("log_buf_len=", log_buf_len_setup);
+/*
+ * Set the delay, in milliseconds, to wait for the console.
+ * @str: Pointer to the start of the delay value
+ * Returns one.
+ */
+static int __init consoledelay_setup(char *str)
+{
+ if (strcmp(str, "forever") == 0)
+ console_delay = CONSOLE_DELAY_FOREVER;
+ else
+ console_delay = simple_strtoul(str, NULL, 10);
+ return 1;
+}
+__setup("consoledelay=", consoledelay_setup);
+
#ifdef CONFIG_BOOT_PRINTK_DELAY
static unsigned int boot_delay; /* msecs delay after each printk during bootup */
@@ -1081,6 +1101,20 @@ struct tty_driver *console_device(int *index)
struct console *c;
struct tty_driver *driver = NULL;
+ /* The console device may not be initialized yet. We can either wait
+ * forever if consolewait is specified on the command line, or wait
+ * for some number of milliseconds if console_delay=msec is used */
+ if (console_delay == CONSOLE_DELAY_FOREVER)
+ wait_event(console_wq, preferred_console >= 0);
+
+ else if (wait_event_timeout(console_wq, preferred_console >= 0,
+ msecs_to_jiffies(console_delay)) == 0) {
+ pr_warning("No preferred console after waiting %ld msec; "
+ "continuing anyway\n", console_delay);
+ pr_info("Increase boot parameter console_delay to wait "
+ "longer\n");
+ }
+
acquire_console_sem();
for (c = console_drivers; c != NULL; c = c->next) {
if (!c->device)
@@ -1230,6 +1264,7 @@ void register_console(struct console *console)
spin_unlock_irqrestore(&logbuf_lock, flags);
}
release_console_sem();
+ wake_up_all(&console_wq);
}
EXPORT_SYMBOL(register_console);
^ permalink raw reply related
* Re: [Patch] Wait for console to become available, ver 3
From: David VomLehn @ 2009-04-20 23:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: stern, linux-kernel, linux-embedded, linux-usb
In-Reply-To: <20090420155033.a89ad4a0.akpm@linux-foundation.org>
On Mon, Apr 20, 2009 at 03:50:33PM -0700, Andrew Morton wrote:
> On Mon, 20 Apr 2009 15:35:00 -0700
> David VomLehn <dvomlehn@cisco.com> wrote:
>
> > On Mon, Apr 20, 2009 at 03:14:00PM -0700, Andrew Morton wrote:
> > > On Mon, 20 Apr 2009 17:51:16 -0400 (EDT)
> > > Alan Stern <stern@rowland.harvard.edu> wrote:
> > ...
> > > > What if a subsystem simply doesn't know in advance whether or not it's
> > > > going to register a console? Or doesn't know when it has finished
> > > > probing all devices (since a new device could be plugged in at any
> > > > time)?
> > >
> > > Fix it. It's trivial to make a sub-driver call back into a higher
> > > layer to tell it that it registered a console. Or just do the
> > > i_will_be_adding_a_console_soon()/oops_im_not_adding_a_console_after_all()
> > > calls from the layer which _does_ know.
> >
> > In the case of the console, we already have register_console(), which is
> > what I'm using. I think your proposal will require adding code all over
> > the place. And buses such as USB simply have no way of knowing whether they
> > are done enumerating devices. A new device could take hours to come on line.
>
> Add a timeout parameter to i_will_be_adding_a_console_soon(). (This
> means that the how-long-to-wait-for policy is probably ahrd-coded into
> the kernel which might be a problem).
Yes, it breaks one problem into a host of smaller problems.
>
> > > Yes, a boot parameter is "simple" to inplement. But it's ghastly from
> > > a usability POV. Especially if you care about boot times. For how
> > > long do you delay? The user has to experiment with different delays
> > > until he finds the magic number. Then he adds 10% and waits for the
> > > inevitable failure reports to come in.
> > >
> > > It's much better to just get it right, even if that makes it more
> > > "complex".
> >
> > With USB, you just can't *ever* get it right. There is no limit on how
> > long a device has to tell you its there. I wish this weren't the case,
> > but our good friends in the USB world tell us that we have been lucky
> > to have had USB consoles work as long as they have.
>
> Sigh, OK, I appreciate the problem better. But the proposed "solution"
> is really quite fragile. I expect that it will only prove usable in
> highly controlled hardware setups.
>
> Is my option a) any use?
I thought about option a). The problem is, given that it might take a very
long time for the console device to appear, you either have to buffer an
arbitrarily large amount of output or simply drop data on the floor. Dropping
log buffer output from printk is one issue, but what's more scary is that
you'll eventually lose data from innocent programs that you start running
from init.
I just don't see any great solutions here; what I've offered is one pragmatic
approach to coming to grips with the Great Unknowns of USB. As Greg KH says,
we're lucky it worked at all. My USB console broke a few months ago and my
primary focus has been to get things back to where, if we are as lucky as
we used to be, things will be no broken than they were. Hey, I'm an engineer,
not a miracle worker!
--
David VomLehn
^ permalink raw reply
* Re: [Patch] Wait for console to become available, ver 3
From: Greg KH @ 2009-04-20 22:53 UTC (permalink / raw)
To: David VomLehn
Cc: Andrew Morton, Alan Stern, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090420223500.GB11068-CFZJ1or75eBPWxJt6d6B6bQa8qPdvLwY@public.gmane.org>
On Mon, Apr 20, 2009 at 03:35:00PM -0700, David VomLehn wrote:
> With USB, you just can't *ever* get it right. There is no limit on how
> long a device has to tell you its there. I wish this weren't the case,
> but our good friends in the USB world tell us that we have been lucky
> to have had USB consoles work as long as they have.
Lucky? You all are _more_ than lucky. USB consoles was a bad hack
written on a drunken dare. I'm still constantly amazed that the thing
even works at all, let alone the fact that people are actually using it :)
The things I agree to over beers, you would think I would learn...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch] Wait for console to become available, ver 3
From: Andrew Morton @ 2009-04-20 22:50 UTC (permalink / raw)
To: David VomLehn
Cc: stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090420223500.GB11068-CFZJ1or75eBPWxJt6d6B6bQa8qPdvLwY@public.gmane.org>
On Mon, 20 Apr 2009 15:35:00 -0700
David VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Apr 20, 2009 at 03:14:00PM -0700, Andrew Morton wrote:
> > On Mon, 20 Apr 2009 17:51:16 -0400 (EDT)
> > Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> ...
> > > What if a subsystem simply doesn't know in advance whether or not it's
> > > going to register a console? Or doesn't know when it has finished
> > > probing all devices (since a new device could be plugged in at any
> > > time)?
> >
> > Fix it. It's trivial to make a sub-driver call back into a higher
> > layer to tell it that it registered a console. Or just do the
> > i_will_be_adding_a_console_soon()/oops_im_not_adding_a_console_after_all()
> > calls from the layer which _does_ know.
>
> In the case of the console, we already have register_console(), which is
> what I'm using. I think your proposal will require adding code all over
> the place. And buses such as USB simply have no way of knowing whether they
> are done enumerating devices. A new device could take hours to come on line.
Add a timeout parameter to i_will_be_adding_a_console_soon(). (This
means that the how-long-to-wait-for policy is probably ahrd-coded into
the kernel which might be a problem).
> > Yes, a boot parameter is "simple" to inplement. But it's ghastly from
> > a usability POV. Especially if you care about boot times. For how
> > long do you delay? The user has to experiment with different delays
> > until he finds the magic number. Then he adds 10% and waits for the
> > inevitable failure reports to come in.
> >
> > It's much better to just get it right, even if that makes it more
> > "complex".
>
> With USB, you just can't *ever* get it right. There is no limit on how
> long a device has to tell you its there. I wish this weren't the case,
> but our good friends in the USB world tell us that we have been lucky
> to have had USB consoles work as long as they have.
Sigh, OK, I appreciate the problem better. But the proposed "solution"
is really quite fragile. I expect that it will only prove usable in
highly controlled hardware setups.
Is my option a) any use?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch] Wait for console to become available, ver 3
From: Andrew Morton @ 2009-04-20 22:35 UTC (permalink / raw)
To: David VomLehn
Cc: stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090420222948.GA11068-CFZJ1or75eBPWxJt6d6B6bQa8qPdvLwY@public.gmane.org>
On Mon, 20 Apr 2009 15:29:48 -0700
David VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> I do agree with the idea of adding one boot parameter rather than two.
zero parameters if at all possible, please...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch] Wait for console to become available, ver 3
From: David VomLehn @ 2009-04-20 22:35 UTC (permalink / raw)
To: Andrew Morton
Cc: Alan Stern, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20090420151400.11afd62a.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Mon, Apr 20, 2009 at 03:14:00PM -0700, Andrew Morton wrote:
> On Mon, 20 Apr 2009 17:51:16 -0400 (EDT)
> Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
...
> > What if a subsystem simply doesn't know in advance whether or not it's
> > going to register a console? Or doesn't know when it has finished
> > probing all devices (since a new device could be plugged in at any
> > time)?
>
> Fix it. It's trivial to make a sub-driver call back into a higher
> layer to tell it that it registered a console. Or just do the
> i_will_be_adding_a_console_soon()/oops_im_not_adding_a_console_after_all()
> calls from the layer which _does_ know.
In the case of the console, we already have register_console(), which is
what I'm using. I think your proposal will require adding code all over
the place. And buses such as USB simply have no way of knowing whether they
are done enumerating devices. A new device could take hours to come on line.
> Yes, a boot parameter is "simple" to inplement. But it's ghastly from
> a usability POV. Especially if you care about boot times. For how
> long do you delay? The user has to experiment with different delays
> until he finds the magic number. Then he adds 10% and waits for the
> inevitable failure reports to come in.
>
> It's much better to just get it right, even if that makes it more
> "complex".
With USB, you just can't *ever* get it right. There is no limit on how
long a device has to tell you its there. I wish this weren't the case,
but our good friends in the USB world tell us that we have been lucky
to have had USB consoles work as long as they have.
--
David VomLehn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch] Wait for console to become available, ver 3
From: David VomLehn @ 2009-04-20 22:29 UTC (permalink / raw)
To: Alan Stern
Cc: Andrew Morton, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.44L0.0904201744410.6832-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
> Personally, I'm in favor of adding a boot parameter. Things could be
> simplified slightly by treating a negative value (or a missing value)
> as indicating an infinite timeout; then only one new parameter would be
> needed instead of two.
I'm allergic to the idea of a user interface using negative one to mean
infinity. It's an bizzare idea that makes sense only to programming
wankers. Such as ourselves. Having a missing value mean infinitity is a
not whole lot better.
I do agree with the idea of adding one boot parameter rather than two. How
about keeping the consoledelay parameter, but allow it to either take a
string, such as "forever", or an integer, which is the number of milliseconds
to delay? I think that will make sense to a lot more people.
Note that, as far as the implementation goes, using a -1 to mean an infinite
wait may very well make sense. I just don't think it makes sense where decent
people can see it.
--
David VomLehn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox