linux-kernel - Re: [Patch] Wait for console to become available, ver 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090420223500.GB11068@cuplxvomd02.corp.sa.net>
Date:	Mon, 20 Apr 2009 15:35:00 -0700
From:	David VomLehn <dvomlehn@...co.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: Re: [Patch] Wait for console to become available, ver 3

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@...land.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.

> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/