> Date: Sat, 27 Oct 2007 17:46:34 -0400 > From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= <askbill_at_conducive.net> > Sender: owner-freebsd-current_at_freebsd.org > > 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). My wetware is subject to too many errors, but I don't think this is 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. 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. 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. You still get the same behavior today if you remove the ATA_STATIC_ID option from your kernel. 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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman_at_es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:20 UTC