--- Alexis Bruemmer <alexisb@xxxxxxxxxx> wrote: > These patches were created in response to the comments from this earlier > email: > http://marc.theaimsgroup.com/?l=linux-scsi&m=114624643916659&w=2 > > First off, thank you Christoph for your comments. I am working to > address them, starting with the ones that are easiest to implement. > Follows is a set of patches that address the following concerns: > > 1) Move the sas readme to the Documents dir-- this still needs to be > written so that it 'matches reality', but I want to merge the sas*.h Which "reality" is this? Christoph's? Anyway, the SAS Stack has seen quite a lot of updates, more than I can list here. Some of them are - Error Recovery, - device lifetimes wholly dependent on kobject references, - SAS transport layer retries, - SAS 2.0 (as much as is available), - SAS domain consistency (pathways, port augmentation, route tables of augmented ports, etc, etc), - SAS versioning: the interconnect declares what SAS version it supports and this is what the SAS Stack drives. - etc, etc, etc. The aic94xx driver has also seen changes: - versioning, - NCQ error handling, - bugfixes on recovery, TMFs, etc. A SAT Layer (SATL) has also been added to the SAS Stack. It conforms to the SAT spec, and uses the SAS task infrastructure. SATL supports the interconnect SATA features: the interconnect declares the SATA features it supports, SATL drives them and so configures SATA devices found on the domain. NCQ is naturally supported. Other interesting features are things like MODE SELECT and READ/WRITE LONG 10/16. 5 VPD pages. Error recovery (NCQ as well). All size-version of commands, i.e. 6/10/12/16 as are defined in the appropriate specs. This is more or less an enterprise effort. The version from which Bottomley started is old. In contrast it did support hot-plugging as the announcement on lkml and lsml said. Now Bottomley is saying that "it [hotplug] still doesn't work". I cannot imagine a customer wanting enterprise reliability, quality and support (as well as technical know-how), to just use the version you're pushing. It just boggles my mind... seeing how much more complex storage is becoming. This is why I asked "which reality" in the beginning of this message. Good luck to everyone, Luben > files to libsas.h and sas.h first > 2) Remove the sas_common.c file > 3) Remove the //depot SCM comments > 4) Remove the expander_conf.c from the kernel tree > 5) Remove various inline functions > 6) Move list_each_entry_reverse_safe from sas_discover.h to list.h > 7) Remove the long queue implementation comment > 8) Use bitops for setting and clearing bits > > These patches are just a start and I will continue to address these > issues. > > Regards, > > Alexis > > - > : 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 > - : 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
