From owner-freebsd-current@FreeBSD.ORG Fri Jul 4 21:54:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCDF81065677 for ; Fri, 4 Jul 2008 21:54:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 445448FC16 for ; Fri, 4 Jul 2008 21:54:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m64Ls0I8069516; Fri, 4 Jul 2008 17:54:01 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 4 Jul 2008 17:33:24 -0400 User-Agent: KMail/1.9.7 References: <20080701181358.GA93601@wep4017.physik.uni-wuerzburg.de> <20080704135827.H35668@woozle.rinet.ru> <22A6B038-44BB-4072-8A6E-8C1D5855CB14@mac.com> In-Reply-To: <22A6B038-44BB-4072-8A6E-8C1D5855CB14@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807041733.25301.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Fri, 04 Jul 2008 17:54:01 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7639/Fri Jul 4 14:44:12 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Alexey Shuvaev , Marcel Moolenaar , Dmitry Morozovsky Subject: Re: puc(4) man page update? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2008 21:54:08 -0000 On Friday 04 July 2008 03:31:41 pm Marcel Moolenaar wrote: > > On Jul 4, 2008, at 2:59 AM, Dmitry Morozovsky wrote: > > > doesn't splitting uart out of kernel broke serial console? Last time > > I checked > > it did. > > Yes, it does. The serial console is setup/initialized and > used before pre-loaded modules are linked and/or usable. > We don't have the support in place that allows you to boot > without console until pre-loaded modules are initialized, > at which time add a low-level console device is setup. > It's not that hard to do, I think. > > So, currently low-level console drivers, such as dcons(4), > sio(4) and uart(4) need to be compiled into the kernel. > Consequently any devices/busses to which any of these can > attach must be compiled into the kernel as well. Of these > acpi(4) and puc(4) are good examples. acpi(4) is a good > example because we use hints to work around the issue and > have sio(4) attach to isa(4) instead... Actually, sio does attach to acpi0. What happens for sio is that the low-level console stuff is just doing bare-bones inb/outb anyway. sioX devices do attach to acpi0 though just fine. Note that in the common case acpi is a module on i386 yet it still manages to work fine. :) Also note that the hints for sio0 aren't actually used, just the 'flags' are applied. Thus, you can have: hint.sio.0.at="isa0" hint.sio.0.port="0x3f8" hint.sio.0.irq="4" hint.sio.0.flags=0x10 But if ACPI lists COM2 before COM1 in the namespace you end up with: sio0 at port 0x2f8 irq 3 (used as serial console!) sio1 at port 0x3f8 irq 4 This is why I wanted to wire devices using the resources in hints so that people would reliably get a serial console on COM1 == sio0 with the existing hints. As it is, people have to engage in far uglier hacks currently since there is no in-tree solution. -- John Baldwin