[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1305324962.2781.5.camel@pasglop>
Date: Sat, 14 May 2011 08:16:02 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"James.Bottomley@...senpartnership.com"
<James.Bottomley@...senpartnership.com>,
Christoph Hellwig <hch@....de>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-scsi <linux-scsi@...r.kernel.org>,
"Jiang, Dave" <dave.jiang@...el.com>,
David Milburn <dmilburn@...hat.com>,
"Ciechanowski, Ed" <ed.ciechanowski@...el.com>,
"Nadolski, Edmund" <edmund.nadolski@...el.com>,
"Danecki, Jacek" <jacek.danecki@...el.com>,
"Skirvin, Jeffrey D" <jeffrey.d.skirvin@...el.com>,
Jeff Garzik <jeff@...zik.org>
Subject: Re: [GIT PULL] isci merge candidate
> 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.
How much of that non-fast-path could/should be in generic code vs. in
the driver specific code ? IE. If somebody comes up with another "dumb"
SAS adapter tomorrow that doesn't do all that magic in an offload CPU,
is any of that code re-usable ?
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists