Re: New-bus unit wiring via hints..

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