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-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
