From owner-svn-src-all@FreeBSD.ORG Mon Jul 13 02:16:32 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70131065670; Mon, 13 Jul 2009 02:16:32 +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 45B908FC08; Mon, 13 Jul 2009 02:16:31 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n6D2GQUx039076; Sun, 12 Jul 2009 20:16:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A5A98FA.3050208@samsco.org> Date: Sun, 12 Jul 2009 20:16:26 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: "Carlos A. M. dos Santos" References: <37131.1247214217@critter.freebsd.dk> <4A56FC7C.8060107@samsco.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r195534 - in head: etc/mtree include lib/libcam sbin/camcontrol share/man/man4 sys/cam sys/cam/ata sys/cam/scsi sys/conf sys/dev/advansys sys/dev/ahci sys/dev/aic7xxx sys/dev/amd sys/de... X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 02:16:33 -0000 Carlos A. M. dos Santos wrote: > On Fri, Jul 10, 2009 at 5:31 AM, Scott Long wrote: >> Poul-Henning Kamp wrote: >>> In message <200907100818.n6A8I8p1011853@svn.freebsd.org>, Scott Long >>> writes: >>> >>>> ATA drives are accessed via 'ada' device nodes. >>> It there a particular good reason why we insist on making this >>> silly mistake every five years ? >>> >>> I am pretty sure you were around when Justin won friends by renaming >>> the SCSI disk devices ? >> 1. I clearly stated that the name is experimental and that a change in >> the future is possible. > > Well, from a user's perspective, if CD/DVD drives are to be seen as > 'cdX', then it would make sense that hard disks were seen as daX, as > already advertised by cam(4). > It gets more complicated than that, even. What about a SAS controller that handles both SATA and SAS disks? Should some disks on the controller be called one thing and some disks be called something else, even though they are both disks? What about intelligent controllers like MPT that do ATA emulation in firmware; SATA and SAS already both show up as 'da' under that controller. How consistent should it be that some disks show up under one name instead of the other name, depending on some feature of controller and/or disk firmware (and I'm not even talking about RAID controllers yet, see below). Should users be expected to care about this level of detail just to get their filesystem created and mounted (and no, this is not a debate about disk and/or filesystem labels, k thx)? SATA vs SCSI/SAS is really just a difference in firmware these days, and it's a difference that the computer should be smart enough to handle transparently in the common case of detecting the disks and doing i/o. Why burden users with caring about the details of a protocol, when all they want to do is access their data? Computers are supposed to automate mundane tasks and decisions like this, not add new mundane tasks and decisions for us to manage by hand. The only time that the protocol matters in a user-visible way is when using camcontrol to manually send a command. I consider camcontrol to be a power-user tool anyways; it's not something that is needed at boot or needed in order to access a USB thumb drive. The only big downside to using the 'da' device moniker for SATA disks is that it hinders people who want to experiment with switching back and forth between the old and new ahci/ata drivers. I feel for these people, and I don't like making their lives hard. But on the other hand, this is a transition period, and experimenting is not without headaches and risks. A day will come, hopefully fairly soon, where switching between the two subsystems is no longer needed, and I don't like catering to a short term need at the expense of a long-term need. One solution to moderate the risk and workload for these experimental users is to add some sort of intelligence to the system that would create 'ad' aliases for 'da' sata disks, but only if the classic ata driver is not present. This restriction would be needed so that there aren't any name clashes in the 'ad' space. Users could then generate some CAM hints to specify 'adX' unit numbers that match what the classic ata driver would use. Another solution is to just bite the bullet and do what I've ultimately wanted to do with disk device names, and create 'diskX' aliases for all direct-access block devices. This would affect hard disks, memory sticks, logical disks like g_raid things, and things that look like hard disks. It would not include cdroms, tapes, etc, that operate on different paradigm than disks. Then you'd have a single handle for both classic ata and new cam devices. There would be a problem with keping unit numbers consistent between classic ata and CAM, though, so this would still present some risk to the experimenter group. However, it also represents where I'd ultimately like this whole disk naming debate to go. What needs to happen in any case is that newbus needs to get out from under Giant. CAM needs to be able to create and destroy devices on the fly, and having to juggle Giant to do that is a step backwards that I don't want to take. Once the newbus problem is solved (and there is already at least one person interested in it, please contact me if you are also interested) then CAM periphs and buses can be made into newbus objects, and the unit numbering for them can be handled consistently and safely though the devclass mechanism in newbus. Once that happens, SATA disks can use 'da' or 'ad' or anything else without conflicts in the unit number space. And then, it's just a question of which color best suits the shed that houses our nuclear reactor. Scott