On Mon, 20 Apr 2009 15:35:00 -0700 David VomLehn <dvomlehn@xxxxxxxxx> 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@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. 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-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
