On Mon, Apr 20, 2009 at 03:50:33PM -0700, Andrew Morton wrote: > 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, it breaks one problem into a host of smaller problems. > > > > 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? I thought about option a). The problem is, given that it might take a very long time for the console device to appear, you either have to buffer an arbitrarily large amount of output or simply drop data on the floor. Dropping log buffer output from printk is one issue, but what's more scary is that you'll eventually lose data from innocent programs that you start running from init. I just don't see any great solutions here; what I've offered is one pragmatic approach to coming to grips with the Great Unknowns of USB. As Greg KH says, we're lucky it worked at all. My USB console broke a few months ago and my primary focus has been to get things back to where, if we are as lucky as we used to be, things will be no broken than they were. Hey, I'm an engineer, not a miracle worker! -- 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
