Re: New-bus unit wiring via hints..

Kevin Oberman wrote:
>> From: Marcel Moolenaar <xcllnt_at_mac.com>
>> Date: Sat, 27 Oct 2007 12:09:29 -0700
>> Sender: owner-freebsd-current_at_freebsd.org
>>
>>
>> On Oct 27, 2007, at 10:58 AM, John-Mark Gurney wrote:
>>
>>> Yeh, you're solution was to simply declare that anyone who knows that
>>> COM1 is at 0x3f8 is wrong, and to use a different, yet again arbitrary
>>> solution which is which is listed first in ACPI...
>> Exactly. Anyone who "knows" that COM1 is at 0x3f8 while
>> the computer right in front of them clearly states that
>> COM1 is at 0x2f8 is in denial.
>>
>>> So, if one ACPI implementation puts _UID = 0 at 0x3f8, but lists it
>>> after _UID = 1 at 0x2f8, that it's fine for sio0 to be _UID = 1?
>> Yes. sio0 is nothing more than the first serial port found during
>> enumeration.
>>
>>
>>> So, why are you continuing to argue about a simple thing that you  
>>> on your
>>> machines can simply remove the hints?
>> The ability to wire is good. Implementing it right
>> is important.
>>
>>>  What are your technical arguments
>>> for mandating a different, non-historical, based arbitrary selection?
>> I'm not mandating anything. I'm merely pointing out how
>> reality has changed and that it's important to adapt,
>> adopt and improve...
>>
>> Where are your technical arguments, putting aside the
>> mere technically of the statement that you consider
>> yourself an old fart?
> 
> "Reality has changed"? Yes, it has, at least a bit, but not to the
> point where we want to confuse serial ports.
>

You are exhibiting are very 'selective' memory (the wetware one).

> Back in the days of v3 and v4, adding an IDE disk to a system could
> cause existing drives to change their device names. This meant that the
> fstab was unexpectedly wrong and things sometimes got messy. The option
> to fix this was added in V4 and moved to GENERIC after a while. Now the
> order in which IDE ports is scanned does not break the device names.

That would be nice - if only it were true.

> 
> If I update my BIOS, the port marked '1' on the back of my system should
> not abruptly change from sio0 to sio1. (Or, because some kernel change
> does this.)  If I have a system with scripts to talk to a device on a
> given port, I would be very annoyed if it suddenly changed.

> 
> In my case, I am only talking to a data logger and not actually
> controlling something, but I should not have to worry about having a port
> name change or finding that _UID1 was no longer the same device if I
> move to a new mother board.
>

Write it in forth or asm such that the hex address of the base port can be 
specified, and you *don't* have to worry about it.

If you want to use a higher-level 'COM(n)' abstraction for script et al 
convenience, then you'll have to pre-assign the base port.

Address decoders, solder, Berg jumpers, DIP swiches, BIOS - one way or another.


> COM1 (or whatever you choose to call it) has been at 0x3f8 since at
> least the IBM-AT and probably was there in the IBM-PC back at the dawn
> of time.

Not so. That's what is pointless about this whole exercise.

You're wanting something nailed-down that you choose to remember as 'fixed' for 
lack of need to have changed it as often as others may have done.

And still do.

But it was never 'fixed'.

Mapping to COM(n) was, and still is, changed of *necessity* to accomodate 
limited hardware and conflicts with other hardware that may have hard-wired 
addressing at ONE end, and 'inflexible' software that expects COM<whatever> at 
the OTHER end. Debugger output, to name one.

Deal with it at whichever end suits your resources. Or in the middle.

But deal with it we must, as the environment is never as 'standard' as we might 
wish.

> (Yes, I had been working with computers for several years
> before then and I suspect many of the others in this discussion had
> been, too.) Please don't break it! Talk about POLA!

Not that it will matter for much longer. Not only laptops, but several 'modern' 
commodity MB have not only shed the DB-9 connector, they don't even ship with a 
cable for the legacy serial header buried on the PCB somewhere.

Boot, and other *storage* device numbering moving about depending on mode, ACPI, 
AHCI BIOS settings is a great deal larger inconvenience.

YOMD, of course... but 'wrong bikeshed'.


Bill Hacker