From owner-freebsd-arch@FreeBSD.ORG Sat Sep 22 19:47:33 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD32B16A417 for ; Sat, 22 Sep 2007 19:47:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.75]) by mx1.freebsd.org (Postfix) with ESMTP id D5C5813C447 for ; Sat, 22 Sep 2007 19:47:33 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpoutm.mac.com (Xserve/smtpout012/MantshX 4.0) with ESMTP id l8MJlXPJ002081; Sat, 22 Sep 2007 12:47:33 -0700 (PDT) Received: from [172.24.104.188] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id l8MJlV5k020947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Sep 2007 12:47:32 -0700 (PDT) In-Reply-To: <22166.1190488551@critter.freebsd.dk> References: <22166.1190488551@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 22 Sep 2007 12:46:13 -0700 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.752.3) Cc: arch@freebsd.org Subject: Re: Replacing/enhancing kernel printf() 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: Sat, 22 Sep 2007 19:47:33 -0000 On Sep 22, 2007, at 12:15 PM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >>>> Are you referring to: >>>> http://lists.freebsd.org/mailman/htdig/freebsd-arch/2006-May/ >>>> 005224.html >> >> Let's define "the low-level console" as nothing more than a >> switchboard. > > The reason I didn't go that route, is that the "streams" > have vastly different sematics, some are even bidirectional. The source vs. sink nomenclature can be confusing, but assuming that all pipes/streams are bi-directional is probably a good way to avoid mistakes. The kernel will ask for input if you boot with -a, so even before we run /sbin/init we need a bi-directional pipe. Of course, display hardware does not allow for input in the same way that a keyboard does not allow for output, but I'm not too concerned about that. It'll fall into place all by itself. For real hardware (i.e. displays, keyboards. etc), there's syscons (or its replacement) that will provide the abstraction and create a single sink into the switchboard. For the msgbuf, we simply have no input coming from that sink ever... I don't see how semantics differ though. Can you give an example? > At the very least you need to think carefully about all of > the four distinct phases: > > Before the kernel runs > Kernel until /sbin/init > /sbin/init and single user mode > Multiuser mode. > > Lumping them all together is what we have today, which we > both recognize as not the way to go. Agreed. We should not lump them together. However, they are interrelated, so we cannot treat them independently either. The switchboard approach was a way to 1) untangle the low- level console from /dev/console and 2) allow everything to be interconnected in some form of shape without backchannels and/or hooks. -- Marcel Moolenaar xcllnt@mac.com