linux-kernel - Re: [GIT PULL] isci merge candidate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 May 2011 17:39:26 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
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

On Fri, May 13, 2011 at 3:16 PM, Benjamin Herrenschmidt
<benh@...nel.crashing.org> wrote:
>
>> 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"

I prefer the word "thin" :-), where "fat" refers to controllers that
hide this logic in offload cpu's, firmware, and or custom asics.

> SAS adapter tomorrow that doesn't do all that magic in an offload CPU,
> is any of that code re-usable ?

At a minimum It would require a more verbose interface to
libsas/libata (or new libframe?) to allow us to deliver raw
unsolicited frames into common protocol handlers.  The concern would
be wrangling different sets of protocol states and exception
conditions that individual vendors would choose to/not to offload.  To
date no other libsas based controller has taken this approach.

--
Dan
--
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/