Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754989AbZDURnP (ORCPT ); Tue, 21 Apr 2009 13:43:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754378AbZDURm4 (ORCPT ); Tue, 21 Apr 2009 13:42:56 -0400 Received: from casper.infradead.org ([85.118.1.10]:33699 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752916AbZDURmy (ORCPT ); Tue, 21 Apr 2009 13:42:54 -0400 Subject: Re: Wait for console to become available, v3.2 From: David Woodhouse To: David VomLehn Cc: David Brownell , alan@lxorguk.ukuu.org.uk, Ingo Molnar , Arjan van de Ven , "H. Peter Anvin" , Thomas Gleixner , Linus Torvalds , Linux Kernel Mailing List , Linux USB Mailing List , Linux Embedded Mailing List , Andrew Morton In-Reply-To: <20090421172929.GC8251@cuplxvomd02.corp.sa.net> References: <20090420234006.GA1958@cuplxvomd02.corp.sa.net> <20090421064346.GB8020@elte.hu> <200904210013.48551.david-b@pacbell.net> <1240333871.3632.70.camel@macbook.infradead.org> <20090421172929.GC8251@cuplxvomd02.corp.sa.net> Content-Type: text/plain Date: Tue, 21 Apr 2009 18:41:05 +0100 Message-Id: <1240335665.3632.71.camel@macbook.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 (2.26.1-2.fc11) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1521 Lines: 32 On Tue, 2009-04-21 at 10:29 -0700, David VomLehn wrote: > On Tue, Apr 21, 2009 at 06:11:11PM +0100, David Woodhouse wrote: > ... > > The kernel output is going to be spewed when a console registers with > > CON_PRINTBUFFER anyway, and if we printk a warning about userspace > > console output being lost, that ought to be good enough to notify the > > user that something may have been lost. For bonus points, we could even > > make that 'dummy' tty driver buffer a limited amount of userspace > > output, maybe. > > What in the world are users going to do when they see a message about > output being lost? There is no way to recover the data and no way to > prevent it in the future. I don't think this is a good approach. > > Remember, even though the previous functionality of USB consoles was, in > theory, less reliable than it appeared, it actually has been working well > for years. Thus, tossing output will count as a regression for most of the > world. So implement a small amount of buffering, as I suggested, and it should be sufficient to cover the cases that were only working before by blind luck anyway. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation -- 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/