From owner-freebsd-arch@FreeBSD.ORG Thu Sep 20 21:18:01 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 C653316A507 for ; Thu, 20 Sep 2007 21:18:01 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.71]) by mx1.freebsd.org (Postfix) with ESMTP id E493913C743 for ; Thu, 20 Sep 2007 21:16:52 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpoutm.mac.com (Xserve/smtpout008/MantshX 4.0) with ESMTP id l8KH1Gci011049; Thu, 20 Sep 2007 10:01:16 -0700 (PDT) Received: from [172.24.104.188] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id l8KH1E3W026161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Sep 2007 10:01:14 -0700 (PDT) In-Reply-To: <200709192257.l8JMvGAQ085614@ambrisko.com> References: <200709192257.l8JMvGAQ085614@ambrisko.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <04C1A383-2376-47DC-92A6-FA1EBF1B9E83@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 20 Sep 2007 10:00:01 -0700 To: Doug Ambrisko 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: Thu, 20 Sep 2007 21:18:02 -0000 On Sep 19, 2007, at 3:57 PM, Doug Ambrisko wrote: > As a person that has done a bunch of appliance work I wouldn't > support this. What I/other companies have done is just to mute > the console and decide on what and when messages of our own should > be displayed. I've read this over a couple of times and it still strikes me as an odd statement. What I posed for discussion is exactly what you've done (or had to do) and yet you don't support it. > What generic mechanism you proprose wouldn't meet everyone's > needs so then it is easier for them to just implement their > needs. I didn't propose anything yet. I merely stated an example. The intend is to find out if a generic method exists that works for everyone, and if not, to what extend we can make it flexible and generic without trying to meet everyone's needs. You advocate that people implement (and re-implement) what they need based on the status quo. I don't see how it is impossible to change the status quo and still have people implement (and re-implement) what they need, provided we don't make things impossible. In other words, if some future infrastructure supports the status quo, no matter how complex we make it otherwise, then your needs are met aren't they? > I think we need to keep FreeBSD simple and selecting a > serial, vga or muted console is fine. No, I don't think it is. For example, we already support using all devices as console with the -D option. With EFI, where multiple consoles can be configured this would be a useful feature so that the OS outputs to the same devices the firmware does. But what about our firewire console or serial over USB? And what about headless setups when there's only a LCD? What I'm trying to say is that a PC-centric point of view as a basis for a design is too limited. You already acknowledge that, because you had to make changes and hack the code to make it fit your needs. So, things aren't fine according to my interpretation. > I also have a patch > so that you can tell the kernel it is a muted, serial console > since that info is lost from the loader -> kernel since > it sets console= so if console=nullconsole then the > kernel doesn't know if the serial console was muted or not. > So I made a new altconsole variable so then we set > console=nullconsole > altconsole=comconsole > so then kernel knows what console is muted. This is very PC oriented. These variables mean nothing on sparc64, powerpc or ia64 for example. There's nothing I can do with what you say here. -- Marcel Moolenaar xcllnt@mac.com