Re: [GIT PULL] isci merge candidate

From: Dan Williams
Date: Fri May 13 2011 - 17:45:22 EST


On 05/13/2011 01:34 PM, Linus Torvalds wrote:
On Fri, May 13, 2011 at 1:14 PM, Dan Williams<dan.j.williams@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/