From owner-freebsd-current@FreeBSD.ORG Wed Apr 20 22:19:03 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C051B1065670; Wed, 20 Apr 2011 22:19:03 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC928FC13; Wed, 20 Apr 2011 22:19:02 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id p3KMIxXg083011; Wed, 20 Apr 2011 16:18:59 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <4DAF46F8.9040004@FreeBSD.org> Date: Wed, 20 Apr 2011 16:18:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DAEAE1B.70207@FreeBSD.org> <20110420203754.GM85668@acme.spoerlein.net> <4DAF46F8.9040004@FreeBSD.org> To: =?iso-8859-1?Q?Ulrich_Sp=F6rlein?= X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , FreeBSD-Current Subject: Re: Switch from legacy ata(4) to CAM-based ATA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 22:19:03 -0000 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