Upcoming plans for CAM

[Scott Long]

Bernard Buri wrote:
> 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.
> 
> 

Yes, a new CCB will be created to encapsulate ATA commands, analogous to
how the XPT_SCSI_IO CCB works today.  Some of the other CCBs that have
SCSI-specific info in them will also be extended or augmented to 
accommodate other protocols and transports.

Scott