Date: Sun, 06 May 2007 08:23:35 -0600 From: Scott Long <scottl@samsco.org> To: Bernard Buri <berni@ask-us.at> Cc: scsi@freebsd.org Subject: Re: Upcoming plans for CAM Message-ID: <463DE4E7.1070506@samsco.org> In-Reply-To: <463D9AAF.4070006@ask-us.at> References: <4628E0DE.2090103@samsco.org> <46290AC6.9020608@ask-us.at> <46292245.3030900@samsco.org> <463D9AAF.4070006@ask-us.at>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?463DE4E7.1070506>