Willy Tarreau wrote:
And when they go to adaptec site to find latest drivers and they only find patches which forces them to find another Linux to install the sources and guess how to patch and build, do you know which OS they consider as hobbyist's ? The Red Hat ! (which they can call "Linux" again then).
Adaptec is unfortunately a special case. QLogic and other enterprise vendors get along with quite well on $100k machines.
Both Luben and his predecessor, Justin Gibbs, were severely dissatisfied with the SCSI core. Often they have raised valid issues that need addressing, but their choice has been to work around or ignore existing code (and maintainers), rather than work with it, and fix it.
When they will buy hundreds of TB of SAS-based racks in the next few years, and they will learn the hard way that Linux does not even see them as disks, it will be too late to give my preferred OS a second chance.
Hardly. SAS support is coming, whether from Adaptec or someone else.
Having read the discussion from the start here a few days ago, I believe that Luben maybe has not explained well to non-competent people like me what the goal of his work is. I've looked at the GIF on T10.org, but I think that the equivalent with what it currently implemented in Linux would be worth doing. Maybe we would even notice that current maintainers cannot agree on a same representation.
The current maintainers seem to agree on the path to transport independence.
Anyway Luben, I fear that for some time, you'll have to provide pre-patched sources as well as binary kernels to enterprise customers who still try to get Linux working in production. I hope that this sad experience will not discourage other vendors from trying to take the opensource wagon, as it clearly brings fuel to closed-source drivers at the moment (no need to argue).
Yes, let's not argue this silliness. Other vendors don't seem to have this level of problem.
Eventhough I don't have SAS, I sincerely hope that a quick and smart solution will be found which keeps everyone's pride intact, as it seems to matter much those days. In an ideal situation, 2.7 would have been opened for a long time, and Luben's code would have been discussed to death as a new development needed to be merged before 2.8. Right now, as 2.7 is 2.6.<odd>, probably that ideas can gem before 2.6.15.
Sigh. This is not about pride. There's already a path to fixing up the SCSI core to work nicely with SAS (and nicer with FC/iSCSI). Changing to a new path midstream, in the middle of addressing the stated problems, causes more delay, more harm than good.
Jeff - : 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
