From owner-freebsd-current@FreeBSD.ORG Tue Oct 30 17:38:56 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 50A1016A4F0 for ; Tue, 30 Oct 2007 17:38:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.83]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0D513C4A8 for ; Tue, 30 Oct 2007 17:38:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp003-s [10.150.69.66]) by smtpoutm.mac.com (Xserve/smtpout020/MantshX 4.0) with ESMTP id l9UH82WM010493; Tue, 30 Oct 2007 10:08:02 -0700 (PDT) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp003/MantshX 4.0) with ESMTP id l9UH7kU0017114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2007 10:07:48 -0700 (PDT) Message-Id: <4B6E9989-28E0-4C73-8F0C-20BB009FAAA7@mac.com> From: Marcel Moolenaar To: John Baldwin In-Reply-To: <200710301015.13245.jhb@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Tue, 30 Oct 2007 10:07:44 -0700 References: <20071027212420.EC7F94500E@ptavv.es.net> <28D8C5EF-8BAB-433D-A6E3-25B2A40B9BD1@mac.com> <200710301015.13245.jhb@freebsd.org> X-Mailer: Apple Mail (2.912) Cc: John-Mark Gurney , freebsd-current@freebsd.org, 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 17:38:56 -0000 On Oct 30, 2007, at 7:15 AM, John Baldwin wrote: >> 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. Doesn't this imply that enumerating on the lexicographical ordering of the (optional) _UID method would help us do what firmware writers intend? In other words, we don't need a number. We just need a means to determine the relative order and we enumerate in that relative order. Isn't that how it is now (and if not shouldn't it be that way)? > Even if a PC has non-standard resources for COM1 and COM2, the serial > ports will show up as sio2 and sio3. This is another sio(4) bug that uart(4) doesn't have, yes :-) > Since you don't care what sio0 > means at all why not let other people who _do_ care have it work on > their > systems? "I" may not care what sio0 means, but that doesn't mean "I" don't care that "my" serial ports aren't numbered starting with 0. >> 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? Correcting the mapping of device instances to physical/visible ports will need to be based on user input. A default mapping, based on the self-enumerating ability of hardware/firmware, may not get it just right in all cases. But may provide a good and reliable starting point that may end up 90+% correct. > 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). I disagree. Since the firmware describes the legacy devices present in the system, the only reliable way is to trust that information. Sure, bugs may exist but 95+% of the FreeBSD code assumes correctness of hardware as it is, so why not in this respect? Anyway, when ACPI describes the hardware, I prefer not to call the legacy hardware ISA devices. It's important to make a clear distinction between enumerating and non-enumerating hardware, because that allows you to create mechanisms for dealing with non-enumerating hardware (i.e. hints) without creating conflicts or ambiguity with enumerating HW. We have convoluted this and mistakenly accepted this convolution as a property of ISA hardware. I've been advocating that our bus-abstraction is a good one. Devices enumerated by ACPI can be said to be attached to an ACPI bus. At least it's not more wrong than saying that they are ISA devices when it's obvious that there's no ISA bus to be found in modern hardware and all the legacy hardware is really on the chipsets LPC bus. > For uart console wiring you use I/O resources for > wiring even. Yes, but not "even". Since bus-enumeration hasn't happened yet, we can not describe the serial console by name+unit, because we have no way of knowing upfront what unit number will be assigned to the UART. The only way you can describe the serial console is by hardware resources or by firmware-level names (such as is the case on powerpc & sparc64). This is why using hints to "mark" the console is wrong. Note also that on ia64 (at least) ACPI tables exist that describe the serial console (and debug port) and those tables use hardware resources. So, the common denominator is I/O resources (even for OFW-based machines) and as it is, it's really the only thing you need (module hardware type) to make a low-level console work. The only correct way to identify hardware for use as low-level console is by it's location in I/O space (module hardware type). This is what uart(4) does and it's one of the reasons uart(4) works on all platforms even though low-level console support is highly machine dependent. It's the right way of doing it and as such it just works. Do not mistake low-level console identification with bus-enumeration device wiring or it being similar to hints. To re-iterate: We should reserve hints for describing non-enumerating hardware (which means device.hints should be non-existent OOTB) and we should add other mechanisms to wire devices to hardware, making use of the fact that underneath it mechanisms exist to enumerate the hardware (incl. hints for non-enumerating hardware). In the future we can replace hints with a more flexible and expressive means to describe hardware so that it better meets the needs of embedded environments and without it impacting device wiring. -- Marcel Moolenaar xcllnt@mac.com