Re: New-bus unit wiring via hints..

Kevin Oberman wrote:
*snip*
>>>
>> You are exhibiting are very 'selective' memory (the wetware one).
> 
> My wetware is subject to too many errors, but I don't think this is one.
>

Sorry - that was meant in re Marcel's belief that the mapping of logical name to 
hex baseport addr of serial ports had [at some point in time | ever] been 'fixed'.

They never were.

Though from IBM ISA onward they were at least a smaller 'pool' of two, three, or 
four.

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

> 
> It is very true and I didn't find it nice. It was fixed in  head on
> Dec. 8, 1999 with the new ATA driver.

That's only a partial 'fix'.

> Prior to that, if you had two
> drives, one on each IDE bus as master, they were numbered 0 and 1. If
> you added a slave disk on the first bus, it became drive 1 and the
> master on the second bus became drive 2. 

An improvement, certainly.

> You still get the same
> behavior today if you remove the ATA_STATIC_ID option from your kernel.
>

Sorry - it is more complex than that, and for (at least) two reasons:

1) Presence of at least two, often three or more *onboard* controllers, not to 
mention those commonly added to the bus.

The entire controller 'block' may be inserted before as well as after the 
'legacy' one(s). Likewise some environments place a bus-attached controller 
before, others after the onboard one(s) in the ordering.

This also changes with BIOS rev & 'race', specifics of the add-on gear, and even 
PCI slot-order. Has done since pre-ISA days, (jumpers, DIP).

Still does so in current MB, such as ASUS P5K and Gigagbyte GA G33-DS3R.

2) Then there are the BIOS options, including 'mode' as in 'IDE', 'Native', 
'Compatible', 'RAID' and/or  'AHCI' enable/disable choices.

Result: Citing just those two newest boards, is that the 'legacy' IDE block 
retains sequence-order, reserving 'seats' 0 thru 3 for devices - attached or 
absent - just as you noted.

That IS 'nice'. But no longer 'enough', and absent PATA devices, perhaps not 
even relevant.

- Supplementary SATA controllers may logically enumerate their 'seats' in EITHER 
forward OR reverse order vs the hardware / MB silkscreen labels, AND may insert 
the resulting block either after or BEFORE the legacy IDE block (0 thru 3) - 
renumber it in the process. /dev/ad0 becoming /dev/ad9, for example.

A casual user is likely to have to deal with at least *part* of that menage, if 
only once... An R&D shop experimenting with the BIOS settings has to keep 
multiple /fstab and paper 'cheat sheets' just to go multi..

That is part of the same 'mapping' issue as serial ports, but is a growing 
problem, whereas serial ports have all but disappeared in any case.

> While I found most of your arguments rather weak, Marcel has me pretty
> much convinced that he is right, so I will not waste everyone's time
> with countering them.

Not interested in 'argument'.

Just pointing out the assumptions about immutability of hex-addr to logical 
device ID are flawed.  Historical OR recent.

That is not going away.

A better 'fix' needs steering options adopted by the BIOS-provider(s).
Don't hold your breath while waiting on those to arrive OR be consistent.

Beyond our control. Plan to adapt.

Bill