Date: Mon, 20 Apr 2009 17:51:16 -0400 (EDT)
From: Alan Stern <stern@rowland.harvard.edu>
To: Andrew Morton <akpm@linux-foundation.org>
cc: David VomLehn <dvomlehn@cisco.com>, <linux-kernel@vger.kernel.org>,
       <linux-embedded@vger.kernel.org>, <linux-usb@vger.kernel.org>
Subject: Re: [Patch] Wait for console to become available, ver 3
In-Reply-To: <20090420143010.697c7380.akpm@linux-foundation.org>
Message-ID: <Pine.LNX.4.44L0.0904201744410.6832-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2169
Lines: 50

On Mon, 20 Apr 2009, Andrew Morton wrote:

> If we want b) then how to do it?
> 
> One possibility: the initcalls have been completed when init_post() is
> called.  How about: if one of those initcalls will be asynchronously
> registering a console, it should inform the console layer about this. 
> It should call the new i_will_be_adding_a_console_soon() function
> within its initcall.  The console subsystem will remember this, and we
> can cause init_post() to block until that registration has occurred.
> 
> We'll need to be able to handle errors, and we'll need to be able to
> handle the case where the initcall function isn't sure whether or not
> it will be registering a console.  So there will also need to be an
> oops_im_not_adding_a_console_after_all() function, which will withdraw
> the effects of i_will_be_adding_a_console_soon().
> 
> Which means that i_will_be_adding_a_console_soon() will need to return
> a handle for the oops_im_not_adding_a_console_after_all() caller to
> pass.
> 
> If init_post() is currently blocked awaiting the arrival of the
> console, oops_im_not_adding_a_console_after_all() will unblock
> init_post() if there are no more potential console registrations
> pending, and inti_post()'s attempt to open a console will fail.
> 
> 
> Or something like that?

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)?

Not to mention that this scheme appears more complicated than the one 
it's intended to replace... although it doesn't have any boot-line 
parameters.

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.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/