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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
