> 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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
