On Oct 30, 2007, at 10:48 AM, John Baldwin wrote: >>> 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)? > > No. They are strings that have no implied ordering. Then there's no problem, for if _UID is designed as a user-visible label and there's no ordering then no-one can claim that one is to be before the other and thus that the logical ordering in the AML is in fact the right ordering. This of course means that the user can see COM2 before COM1 in some user-interface. This of course is exactly in accordance with the firmware and as such correct. >>> 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 :-) > > Hmmm, I don't think you parsed what I meant, but maybe you mean that > uart(4) > doesn't have the poorly-implemented "feature" in sio(4) to make sure > that all > non-ISA serial ports start at unit 2 to "reserve" sio0 and sio1 for > COM1 and > COM2? Exactly. > Just look in sio_pci.c for 'device_set_unit()' which the current > wiring patches remove with a vengance by making hints always reserve > a given > (name, unit) tuple. And since hints are shipped by us with default values, what we did is remove the poorly-implemented "feature" from sio(4) only to bank on hints to yield the same result, which makes hints nothing more than a different poorly-implemented "feature" :-) >>> 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. > > And you could have an empty hints file and be happy. With the exception of course of having an OS that does the wrong thing OOTB and that requires extensive fiddling to behave correctly, increasing the amount of maintenance and upgrade hassle. >>>> 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. > > Oof. See, here is where I think we hit a snag. :( I'm thinking in > terms of > automated installations to a wide variety of server boxes that don't > have > a GUI with a mouse and monitor hooked up so a user can clicky-clicky > to set > which serial port is sio0. :( I don't see a snag. But maybe that's because I use uart(4) on my machines and I have a serial consoles no matter how things are enumerated... >>> 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? > > You've missed the point of this entirely then. :( Yes, the firmware > is > authoritative, and part of the goal is to fix a long-standing > weakness where > the OS is presented with two different enumerations of hardware: one > supplied > by the user via hints and one supplied by the firmware. The "weakness" you mention is really the OSes own failure by "presenting" itself with hardware information that has no relation to the machine that it runs on, because it's actually fixated by virtue of being part of the OSes source code. It isn't supplied by the user at all. We supply it to ourselves. Don't go blaming the user for that... > The idea is to trust > the firmware's notion of resources since it probably knows better > while > allowing for other non-resource information provided by the user to > be tied > to the correct piece of hardware. Agreed... He, that's what I said previously and you responded to with saying that we hit a snag. I guess we don't then; or do we? I'm confused now :-) >> 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. > > You continue to ignore that ACPI is not just a simple bus, but is a > namespace > that enumerates devices on multiple busses such as ISA/LPC, SMBus > (e.g. an > IPMI SSIF interface can be enumerated via ACPI), etc. It is much more > generic than just an ISA enumerator like PNPBIOS. No, I don't ignore anything. I explicitly and deliberately use the term "abstraction". It's a simplified representation of reality. An "idea". My choice of calling ACPI a bus is probably what confuses you. I'm fully aware that it is much more than a bus, but it still "quacks" like one WRT legacy hardware... >>> 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. > > So what do you want: 'wire.sio.0.*?' Or do you want XML or some > binary > registery like Windows that can't be modified by the user w/o first > booting > the OS (which is real handy when it gets corrupted). What I want is something that is appropriate. If we want to wire hardware to devices, then we need to be able to uniquely identify a device in hardware. A path if you will that mentions busses, bridges devices and functions therein. Look at ACPI, EFI and OFW for example. Such an identification is the keying entity. Data that corresponds to that key can be complex or compound so that you can actually specify which driver you want to use above and beyond simply wiring it to a unit number. This also also allows us to add other pieces of information. I'm not going to give concrete examples, because I foresee that the discussion will then be about how my "solution" sucks rather than it being treated for what it is: an illustration -- something to explain what I said and in no way complete or even usable. Ok, what the heck. For better or for worse: \begin{/boot/hardware.conf} # Lines starting with '#' are comments [pci0.0.18.0] # First function: standard UART # We use this for remote GDB driver="sio" unit=2 dbgport="9600,n,8,1" [pci0.0.18.1] # Second function: standard but memory-mapped UART # doesn't work with sio(4) -- needs uart(4) # We use this one as console. driver="uart" unit=3 console="115200,n,8,1" \end{/boot/hardware.conf} Don't get confused about marking the hardware as console or debug port and how we do the same in hints. It isn't the same. Hints mark the driver instance as console or debug port. Here I mark the *hardware* as console or debug port, even if we don't wish to wire it to a driver instance (although we do in the example) Fundamentally different! > Right now the current "solution" results in various places (like my > employer) > just turning off the ACPI support for sio(4) because hints are more > reliable > for us than ACPI when it comes to enumerating serial ports in _real_ > _world_ > _x86_ server-class machines. Use uart(4)? -- Marcel Moolenaar xcllnt_at_mac.comReceived on Tue Oct 30 2007 - 19:00:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:20 UTC