Upcoming plans for CAM

[Scott Long]

Bernard Buri wrote:
> Scott Long wrote:
>> All,
>>
>> Now that the MPSAFE work is mostly done and settled, it's time to move
>> onto the next phase of the overall work.
>>
> this is great news!
> I've been working with the CAM layer in my last project, and I loved it. 
> It is the most advanced scsi stack I've seen, so I'm glad it gets some 
> refinement now.
> 
>> ...
>> SATA and IDE transports, ATA protocol
>> -------------------------------------
>>
>> The transport modularization work described above will allow non-SCSI
>> transports to be easily added.  So, the next step is the long-promised
>> unification with IDE and SATA.  Instead of hacks like atapicam and
>> atacam that try to force IDE/SATA into the SCSI model, a whole new
>> subtransport will be written that understands the topology and nature of
>> the devices, as well as natively understanding the ATA command set.
>>
>> There are still some interesting design questions that need to be
>> answered here.  SATA controllers essentially use a star topology instead
>> of a bus topology.  So does it make sense to treat all devices as each
>> having a private bus, or is it better to have a single virtual bus?
>> Also, ATAPI devices basically speak the SCSI protocol so they'll attach
>> to things like the 'cd' driver, but ATA disks speak ATA, which is very
>> different from SCSI.  Should they get their own unique peripheral
>> device, or should they be part of the 'da' device?  If they get their
>> own peripheral device, should they still generate '/dev/da' device
>> nodes, or should they retain the current '/dev/ad' naming?
>>
> I think that for the user, the device name doesn't really make a 
> difference. Like with network interface cards, it is not a problem that 
> some of them show up as fxp*, while others show up as myk*. As long as 
> there is not a separate fxpconfig and mykconfig tool.
> 
> I think for the way cam is desigend right now, it is more intuitive to 
> have separate device names.
> 
> In fact, I don't know much about ATA disks. I recognized recently, that 
> SATA disks show up as /dev/sdX on linux while PATA disks show up as 
> /dev/hdX. And SATA disks are said to be compatible to serial attached 
> scsi. Does it mean that only PATA disks will be /dev/ad* ?
> 

First of all, a distinction needs to be recognized between the transport
and the protocol.  The transport basically describes how the device is
connected to the system.  It could be a SATA bus, it could be a SAS
expander, it could be a parallel SCSI bus, etc.  The protocol describes
what language the device speaks.  That could be SBC (SCSI Block
commands), MMC, ATA, etc.  Both IDE and SATA disks speak the ATA command
protocol, regardless of how they are attached to the system.  However,
SATA disks can be on a SATA transport or on a SAS transport.  The
changes I'm proposing address exactly this; no longer will CAM be purely
parallel SCSI specific with hacks to support other things, it'll
recognize the different transports and protocols and allow them to be
mixed together in whatever way the SIM allows.

On the Linux side of things, they're basically kinda sorta doing the
same thing, though less elegantly.  They wrote a SATA shim for SCSI a
few years ago (libata), and are now in the process of trying to expand
that to do the same modularization of the transport that I'm proposing.
However, they're stopping at only supporting SATA under this new scheme,
leaving all IDE to the old hd driver.  I intend to support IDE since
it's still a very common transport, especially for CDROMs.

As for the device naming issue, one of the original intentions of CAM
was to unifying the naming scheme.  A disk should be a disk, it
shouldn't matter what the transport or protocol is.  Those are details
that should get handled transparently.  At the same time, the situation
in linux is showing that users are getting unhappy with traditional
device names changing.  Linux is making it harder than it needs to be
because of how they name IDE CDROMs, but that's baggage that is unique
to Linux, not FreeBSD.  But, it's still a consideration that should not
be overlooked.

Scott