Re: [GIT PULL] isci merge candidate

[Dan Williams <dan.j.williams@intel.com>]

On 05/13/2011 01:34 PM, Linus Torvalds wrote:
> On Fri, May 13, 2011 at 1:14 PM, Dan Williams<dan.j.williams@intel.com>  wrote:
>>
>> [ Linus, only cc'ing you in case a new-driver merge exception can be
>> entertained at this very late date.  James made clear he needed this in
>> advance of rc7, and this still needs Christoph's ack, but I would be
>> remiss not to send this after reaching this milestone...]
>
> So I can merge new drivers at any stage in the development cycle, but
> I only do that for drivers with mass appeal.
>
> What's the likely user base of this?

This storage controller is integrated into the chipset that will be the 
basis for upcoming workstation / server platforms.

> Why is it a SCSI driver rather than SATA? Why is it so f&*%ing big?

It's a SAS (serial-attached-scsi) driver so it ties in to libsas rather 
than libata (libsas itself ties in to libata for tunnelling SATA 
protocol over SAS).  The size is attributable to the fact that all 
protocol handling for non-fast path i/o is handled by software.  There 
are still cleanups that can be made, but likely not on the on the same 
order of what we have already done.

> The size may be a massive improvement over what it has been, but if
> this is some kind of replacement for the current AHCI situation, it's
> still a massive step backwards.

So it's not a replacement for AHCI and AHCI will still be included in 
this chipset.  However, AHCI in this timeframe only gives you up to 
4-ports at 3Gb/s and 2-ports at 6Gb/s direct attached SATA.  This 
controller in comparison includes up to 8-ports 6Gb/s of SAS/SATA 
connectivity allowing drives to optionally be connected through an 
expander topology.

> So what does that mean in practical terms:
>
>   "This driver supports the 6Gb/s SAS/SATA capabilities of the upcoming
> Intel(R) C600 series chipset family"
>
> exactly? What's the market for that C600 series?

Standard workstations and servers.

> Does that chipset
> also do some AHCI emulation capability (making this driver be a "if
> you need full capabilties thing" etc) Yadda yadda.

Yes.  We expect the majority of platforms to populate at least some of 
the AHCI ports.  That being said populating zero AHCI ports is also a 
valid configuration option and some platform vendors may take this route.

> I don't want to merge 30k lines of driver that nobody will practically
> speaking actually use.

I will note that if a user is on a platform without AHCI they will be 
missing ATAPI support as that was a feature of the isci driver that was 
deferred while the cleanup/rewrite was happening.

--
Dan