From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 16:56:00 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A967516A41F for ; Fri, 2 Sep 2005 16:56:00 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F75843D49 for ; Fri, 2 Sep 2005 16:56:00 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j82GtxS0014515; Fri, 2 Sep 2005 09:55:59 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <34182.1125646759@phk.freebsd.dk> References: <34182.1125646759@phk.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75AF001F-473A-4D0E-9DF5-5A25F02B3749@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 2 Sep 2005 09:55:57 -0700 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.734) Cc: arch@freebsd.org Subject: Re: Consoles, past and future. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 16:56:00 -0000 On Sep 2, 2005, at 12:39 AM, Poul-Henning Kamp wrote: > 1. Kernel boot progress indicator. > All the device probe and attach etc. > API: printf(9) and friends. > > 2. Single user terminal connection > For manually fixing things before /etc/rc is run. > API: Any tty(4) (and various other) devices will do. > > 3. System initialization progress indicator. > The output from /etc/rc and its spawn. > API: any file, pipe, stream socket and most devices will do. > Using a tty(4) gives the ability to SIGINT processes which > hang/sleep/get confused during startup. 2 & 3 are in essence the same thing currently. That is, both depend on the tty device /sbin/init uses. Whether they should be the same thing or not is not expressed with this statement. > gdb(9) has its own hooks into the device driver. I'm not sure I > know why, but it probably makes sense. Because a debug port is not a tty. The communication over a debug port is not bound to the rules and regulations of a tty. It therefore demands a separate interface. That you can implement one in terms of the other is merely an upshot. If we want to think radically, we probably should shift our thinking. We still treat the console as a central and fundamental piece of the kernel. I think we should instead make a 180 degrees turn and start off with a kernel that's deaf and dumb. I think it goes without saying that such an OS is still functional. Now, with this flatscreen or CRT in front of us, it would be nice to actually make use of it. But for what I hear you think... What is the use of a display? Well, it's a feedback device. We interact with the machine by looking at the display and act on what we see. This also means that the use of a display is dictated by the the abilities of the user, the role the machines plays in the user's life and the role of thew user in relation to the machine. In concreto: We have end-users, sysadmins, developers and machine builders as our possible audience and related to that we have FreeBSD ranging from a home computer to a hardware validation vehicle. The feedback appropriate in each of those scenarios is different. If we have disabled users, a display may not even be usable as a feedback device in the first place... What this means is that printf(9) can never mean the same as printf(3). It makes more sense to have printf(9) be the interface to internal logging and use a completely separate mechanism for sending the log information to some device if such would be beneficial. This allows us to not display the boot probe gobbledegook so that we can present the end-user with a nice logo instead as well as allows us do the complete opposite and and make all those weird developers happy. In any case, this concept cannot be explained in an email that's written on the verge of me going to work, so let me end here and see what grows from the seed that has been planted. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net