Date: Wed, 20 Apr 2011 16:18:59 -0600 From: Scott Long <scottl@samsco.org> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= <uqs@spoerlein.net> Cc: Alexander Motin <mav@freebsd.org>, FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: Switch from legacy ata(4) to CAM-based ATA Message-ID: <BCE89DC7-116D-48E1-BD86-DF986062B0CC@samsco.org> In-Reply-To: <4DAF46F8.9040004@FreeBSD.org> References: <4DAEAE1B.70207@FreeBSD.org> <20110420203754.GM85668@acme.spoerlein.net> <4DAF46F8.9040004@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: > Ulrich Sp=F6rlein wrote: >> Can we then please get the "ad" device prefix back? I seem to = remember >> that when they were introduced they were thought to be a temporary = thing >> ... >>=20 >> Unless both stacks can run in parallel, I don't see a problem with >> having them both show up as /dev/ad0, etc. People with problems must >> send in a complete dmesg anyway, so it should be clear what stack = they >> are running. The POLA violation for people upgrading from 8.x to 9.0 >> however is pretty big ... and unnecessary. >=20 > Stacks do can run in parallel, and it really happens when people = loading > ahci(4) driver for SATA disks without using `options ATA_CAM` of = ata(4) > for PATA. As result, SATA will use new stack and PATA - old one. >=20 > What's about POLA violation, it is inevitable, because present kernel > uses ata(4) with ATA_STATIC_ID option, that is not applicable in = modern > SATA world order. So at least device numbers will change. >=20 > Also you should take into account, that many people and some software > already adapted to adaX names and change back will break POLA for = them. I agree with what Alexander is saying, but I'd like to take it a step = further. We should all be using either mount-by-label, or be working to = introduce generic device names to GEOM. Right now, device names are an = implementation detail that have no functional use other than to = complicate the fstab. Disks exposed through the block layer are simply = direct-access block-array devices, nothing more. There's no functional = difference to the kernel or userland between ad, ar, da, aacd, mfid, = amrd, etc when it comes to reading and writing sectors off of them. But = yet we give them unique names and pretend that those names mean = something. We could give them all the name of "disk" and the system = would still function exactly that same. The name attributes are = interesting when it comes to doing out-of-band management, but it's also = trivial to create a human-readable map and a programatic API between the = generic name and the attribute name. Same goes for volumes labels, and = I'd almost argue that they're more powerful than generic device names. In other words, "ada" isn't the problem here, it's that we all still = think in terms of the 1980's when systems didn't autoconfigure and = device names were important hints to system functionality. That time = has thankfully passed, and it's time for us to catch up. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BCE89DC7-116D-48E1-BD86-DF986062B0CC>