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

[Scott Long]

Carlos A. M. dos Santos wrote:
> On Fri, Jul 10, 2009 at 5:31 AM, Scott Long<scottl at samsco.org> wrote:
>> Poul-Henning Kamp wrote:
>>> In message <200907100818.n6A8I8p1011853 at 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