From owner-freebsd-current@FreeBSD.ORG Fri Oct 12 20:38:20 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5548316A418 for ; Fri, 12 Oct 2007 20:38:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 1615513C46B for ; Fri, 12 Oct 2007 20:38:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 214179132-1834499 for multiple; Fri, 12 Oct 2007 16:36:22 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l9CKc8Ke042183; Fri, 12 Oct 2007 16:38:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Fri, 12 Oct 2007 16:20:59 -0400 User-Agent: KMail/1.9.6 References: <200710111741.34992.jhb@FreeBSD.org> <200710121409.31407.jhb@freebsd.org> <7C92FD4D-39DA-4AAE-A0F6-4D856AAD46EE@mac.com> In-Reply-To: <7C92FD4D-39DA-4AAE-A0F6-4D856AAD46EE@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710121620.59787.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 12 Oct 2007 16:38:09 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4533/Fri Oct 12 06:59:29 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: New-bus unit wiring via hints.. 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, 12 Oct 2007 20:38:20 -0000 On Friday 12 October 2007 03:49:28 pm Marcel Moolenaar wrote: > > On Oct 12, 2007, at 11:09 AM, John Baldwin wrote: > > > On Thursday 11 October 2007 05:59:23 pm Marcel Moolenaar wrote: > >> > >> On Oct 11, 2007, at 2:41 PM, John Baldwin wrote: > >> > >>> 2) One of the things this fixes that is visible to users is that if > >>> your > >>> machine gets the COM ports backwards when using ACPI it should > >>> now get > >>> them correct (COM1 as sio0) assuming your COM ports use the > >>> default hints > >>> and you have the default sio hints in your /boot/device.hints > >>> file. > >> > >> I think you just pointed out the problem of using hints to wire > >> down unit numbers, because hints will stop hinting and will start > >> dictating. If I swap the serial ports in the BIOS then surely > >> my hints will be wrong and ACPI will be right. A default hints > >> file will be even more disastrous than before. > > > > hints have always dictated. The issue is that hints are > > enumerating devices > > that ACPI/PNPBIOS also dictate, so how does one resolve the > > differences (do > > you ignore one or the other, or attempt to merge them, etc.). Note > > that > > hints can always be removed. > > I think the conflict is resolved by having hints only apply to the isa > bus proper and stop tying apci to the isa bus. This also exposes other > flaws with hints, such as using flags to mark a device as (potential) > console. The issue here is that the 16550 UART that ACPI enumerates is on the LPC bus, that is, it's an ISA device. In this case, ACPI is subsuming the role of the PNPBIOS to enumerate ISA devices. If you want to move all the ACPI-enumerated ISA devices under isa0 (which we can do, similar to how the ACPI pci(4) driver "claims" the ACPI handles for PCI devices in the ACPI namespace) we can do that, but that doesn't solve the problem at all. The problem is, ACPI is not a "bus". It's a hierarchical namespace that spans multiple busses, including PCI, ISA/LPC, etc. We don't probe PCI devices based on them showing up in ACPI's namespace, we probe them based on PCI's normal enumeration process. One of purposes of ACPI is to enumerate devices on busses that are too dumb to provide their own enumeration (e.g. non-PnP devices on ISA). > > FWIW, the resources for COM1 and COM2 are largely fixed in practice on > > existing x86 hardware which is what this would affect, and hints > > can always > > be removed. Given the number of complaints from people where ACPI > > enumerates > > COM2 before COM1 (and the fact that ACPI made _UID useless by not > > giving it a > > more strict format.. it's optional and on some systems it is 0- > > based while on > > others it is 1-based. > > But aren't the complaints the immediate result of having hints in the > first > place. Remove the hints and the complaints go away, right? No. The kernel console switches because it is bound via hints. Besides, people also don't like the cosmetics of having ttyd0 being COM2 and ttyd1 being COM1, etc. > > I've also seen pci link devices where the _UID is the > > link index from the $PIR table which == the register offset in > > config space > > on the PCI-ISA bridge of the controlling register) and the fact > > that COM1 and > > COM2 have de-facto fixed resources on x86, I think it's ok for x86 > > to include > > default hints for sio0 and sio1. > > If the hints would be specific to the ISA bus, then it would > definitely be > ok to have them. Even though we don't support i386 hardware, it > should not > be a big deal to keep the support for the ISA bus. We should really stop > using acpi as an alias for isa and start treating it as a separate > "bus". See above. ACPI != bus. ACPI == namespace that spans multiple busses. This is an important distinction. > > Do you have any comments on the idea in general of allowing busses > > to use > > hints (or some other method) to wire devices to unit numbers? > > Wiring unit numbers to particular devices is good. Tying them to hints > isn't. I would rather see us go in the direction of having the kernel > maintain a configuration file. This would allow us to extend the notion > wiring down unit numbers to keeping state across reboots. This could > be used in the future for various cases, such as: > o video/graphics settings > o console settings > o fast boot or suspend from disk information > o user specified labels or aliases for devices/disks > o interrupt routing overrides > o quirks > o etc > > No matter how we implement the wiring, one major issue is that the > information can be out of sync if the hardware configuration is changed. > It would be nice to have at least a boot option that tells the kernel > to ignore all the wiring information. It would allow one to boot the > kernel, correct any conflicts that would otherwise prohibit the kernel > from booting normally and restart. > Of course, if the wiring is done with hints, that would then also mean > that all the hints are ignored, which currently means that drivers that > abuse hints won't get started (i.e. syscons). That's another reason to > uncouple hints from wiring. We currently can't boot without hints even > though all hardware is found without hints -- we misuse hints as it is. > > Just my $0.02, This would be to go backwards to 4.x which put the "hints" data into the kernel config file meaning you can't change it at boot-time in the loader. If you want the configuration file separate from the kernel, then what do you consider /boot/device.hints to be? -- John Baldwin