Upcoming plans for CAM

[Bernard Buri]

Scott Long wrote:
> 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

Ok, but I think currently, there is no peripheral device driver that 
really handles fundamentally different protocols right now ?

One example: The ch driver handles one protocol (media changer). I did 
work with cd jukeboxes and wrote my own drivers, using the pass driver. 
Though there are some differences (quirks), all these jukeboxes are 
talking the same protocol.

On the other hand, there is another protocol for LUN based cd changers 
that are not supported by my code because they talk a fundamentally 
different protocol.

With CAM, it's the same: ch driver handles "multi-target" changers and 
cd driver handles "multi-lun" changers.

The impression I have (concerning CAM) is that: One SCSI Peripheral 
Device Type (Standard Inquiry Data) gets one peripheral device driver:
0x00 = da, 0x01 = sa, 0x05 = cd, ...

The impression I have (concerning SCSI) is that: One SCSI Peripheral 
Device Type (Standard Inquiry Data) corresponds to one "set of 
protocols", the device is supposed to talk.

I think the main question for the non-kernel-developer (me) concerning 
the integration of (S)ATA disks into CAM is:

Would it even be possible to work with ATA disk commands via the cam(3) 
API ?

I think if it is physically possible to transport SATA disk commands via 
SAS, it should definitely be possible to use the cam(3) API to send 
these commands (via pass).

For this, it doesn't really matter which peripheral drivers are attached 
to the device beside the pass driver. Whether the da driver handles 
(S)ATA commands directly is only a matter of modularization, but I agree 
now, that the (S)ATA disk should get a /dev/daX device entry.