From owner-freebsd-current@FreeBSD.ORG Fri Jul 4 23:11:22 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 D7E841065686; Fri, 4 Jul 2008 23:11:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.67]) by mx1.freebsd.org (Postfix) with ESMTP id B5A468FC0A; Fri, 4 Jul 2008 23:11:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtp021-bge351000.mac.com (asmtp021-bge351000 [10.150.69.84]) by smtpoutm.mac.com (Xserve/smtpout004/MantshX 4.0) with ESMTP id m64NBMv1027595; Fri, 4 Jul 2008 16:11:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.102] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0K3I005GH8EW6S60@asmtp021.mac.com>; Fri, 04 Jul 2008 16:11:22 -0700 (PDT) Message-id: <0D68D063-6654-4E55-ACA9-A0B58C7AA45C@mac.com> From: Marcel Moolenaar To: John Baldwin In-reply-to: <200807041832.40605.jhb@freebsd.org> Date: Fri, 04 Jul 2008 16:11:20 -0700 References: <20080701181358.GA93601@wep4017.physik.uni-wuerzburg.de> <200807041733.25301.jhb@freebsd.org> <70771DF0-71BB-453F-949E-6A50DD7D0D71@mac.com> <200807041832.40605.jhb@freebsd.org> X-Mailer: Apple Mail (2.926) Cc: Alexey Shuvaev , freebsd-current@freebsd.org, 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 23:11:23 -0000 On Jul 4, 2008, at 3:32 PM, John Baldwin wrote: > On Friday 04 July 2008 06:06:48 pm Marcel Moolenaar wrote: >> >> On Jul 4, 2008, at 2:33 PM, John Baldwin wrote: >> >>> 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. >> >> That's because sio(4) compiles-in the acpi bus attachment >> even if acpi is not compiled-in. That's cheating :-) > > No, that's how new-bus works. :) It's perfectly fine to do that. In general, yes. How sio(4) does it, no. sio(4) tied acpi(4) with isa(4) so that if you get the acpi(4) bus attachment when you have isa(4) compiled-in. Consequently, you lose acpi(4) support if you build a kernel without isa(4) support. You also accidentally avoid the problems of having acpi(4) as module. It's a kluge. On ia64 we need acpi(4) but we can't have isa(4), so it's not a generic solution at all. > The > attachments get bound at runtime. This is actually an important > feature. It's an important feature of KOBJ, yes. The point of compiling drivers into the kernel is to get just what you need. Not a bunch of bus attachments you don't want. Modules have pretty much all bus attachments because they need to work with whatever kernel they're loaded in. So, sio(4) is not following the rules in the strictest sense. That's why sio(4) is a bad example, why the problem is not adequately acknowledged and people keep running into the same old problems of things not working "as expected". -- Marcel Moolenaar xcllnt@mac.com