Re: New-bus unit wiring via hints..

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