From owner-freebsd-current@FreeBSD.ORG Tue Oct 30 15:02:51 2007 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 5EE5E16A469 for ; Tue, 30 Oct 2007 15:02:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 470B713C4A3 for ; Tue, 30 Oct 2007 15:02:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id E616F1A4D87; Tue, 30 Oct 2007 07:36:19 -0700 (PDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 30 Oct 2007 10:15:12 -0400 User-Agent: KMail/1.9.7 References: <20071027212420.EC7F94500E@ptavv.es.net> <28D8C5EF-8BAB-433D-A6E3-25B2A40B9BD1@mac.com> In-Reply-To: <28D8C5EF-8BAB-433D-A6E3-25B2A40B9BD1@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710301015.13245.jhb@freebsd.org> Cc: John-Mark Gurney , Marcel Moolenaar , 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: Tue, 30 Oct 2007 15:02:51 -0000 On Saturday 27 October 2007 06:04:40 pm Marcel Moolenaar wrote: > > On Oct 27, 2007, at 2:24 PM, Kevin Oberman wrote: > > >> From: Marcel Moolenaar > >> Date: Sat, 27 Oct 2007 13:57:25 -0700 > >> > >> > >> On Oct 27, 2007, at 12:40 PM, Kevin Oberman wrote: > >> > >>>> I'm not mandating anything. I'm merely pointing out how > >>>> reality has changed and that it's important to adapt, > >>>> adopt and improve... > >>> > >>> "Reality has changed"? Yes, it has, at least a bit, but not to the > >>> point where we want to confuse serial ports. > >> > >> Are you saying that "we" should accept reality's change > >> only for as far as it doesn't confuse "us" ??? > > > > Just in case I don't understand the issue, feel free to correct me, > > but > > it sounds like you are saying that there will not be a clear link > > between the serial port (sio) number and the port marked '1' on most > > systems. If I am wrong about this, please tell me and I climb back > > under my rock. > > That is not what I'm saying. What I'm saying is: > If the firmware tells the OS that the port marked > "1" on the back corresponds to a UART that has a > base I/O port address of 0x2e8, then who are we > to disagree and demand that it should be 0x3f8? That isn't what is happening though. The port marked "1" is at 0x3f8 and happens to be "later" in the namespace than the port marked "2" which is at 0x2e8. The BIOS may _optionally_ decide to communicate this to the OS via the _UID method, but the _UID is only guaranteed to be a string that it suitable for use in a label in a GUI dialog box. The BIOS may use _UID's of "0" and "1", or "1" and "2", or "COMA" and "COMB". And it may not even supply any _UID values at all. If you want to bind by _UID I already have support for having: hint.sio.0.at="acpi0" hint.sio.0.uid="COMA" However, that 1) does not work out of the box since there is no "standard" format of _UID, so there aren't any default _UID values we can use and 2) does not work on the many boxes where the BIOS does not provide a _UID to begin with. Matching on resources does work for any off-the-shelf x86 box you can go buy at the store though. Even if a PC has non-standard resources for COM1 and COM2, the serial ports will show up as sio2 and sio3. Since you don't care what sio0 means at all why not let other people who _do_ care have it work on their systems? In the case of that system if someone really wants to fix it they can always adjust their hints, and they can even do so in the loader before the kernel is booted if it matters for install, etc. > You rightly point out that what it really boils > down to is how devX maps to a port on the back or > front of the machine. This mapping should not > change gratuitously. Device wiring achieves that. But on what basis will you wire things? The only currently reliable way I can see to wire things on x86 for an ISA device (and yes, the COM port on a PC is ISA even if ACPI is what enumerates it rather than PNPBIOS) is I/O resources or the name of the device in the ACPI namespace (ACPI-only). The latter is hard to get right as well since there is no standardized format for device names. Shoot, my laptop I have for work intentionally obfuscates all method/device/etc. names in the namespace that aren't using a standardized name like _SB_ or _PRS to be Cxxx where 'xxx' is a hexadecimal value so you end up with locations like \_SB_.C003.C026.C02A. ACPI's _UID is unreliable as mentioned above. For uart console wiring you use I/O resources for wiring even. > > The new system has, to the typical user's eyes, the same > > configuration. > > Yes. this means there's a gap between what the user sees > (the chassis) and what FreeBSD sees (the mainboard). As > long as the mainboard is designed for the chassis, that > gap is mostly non-existent or insignificant and what the > firmware tells the OS is what you see on the back (or > front). Otherwise, all bets are off... FYI, on many systems the '1' and '2' (or 'A' and 'B') labels are actually on the mobo, not on the chassis. -- John Baldwin