On Fri, May 13, 2011 at 3:16 PM, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> 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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
