Re: New-bus unit wiring via hints..

On Tuesday 30 October 2007 01:07:44 pm Marcel Moolenaar wrote:
> 
> 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)?

No.  They are strings that have no implied ordering.

> > 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?  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.

> >  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.

> >> 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. :(

> >  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 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.

> 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.

> >  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).

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.  I'd much rather be trusting ACPI myself hence 
my attempts to make the two sets of information enumerating the same hardware 
agree on what they are talking about.

-- 
John Baldwin