Salyzyn, Mark wrote:
Jeff Garzik [mailto:jgarzik@xxxxxxxxx] sez:
All throughout development, before Justin had written a
single line of code, he was told to do things via Device Mapper.
He did not strictly write the emd code, it was written years earlier by
a team. It's release was the result of it being placed on his lap
submit.
Ah, I stand corrected.
I just recall being on concalls months prior to public EMD release,
urging the use of Device Mapper, and telling Adaptec and other involved
companies that the submission would be rejected if the current course
was continued.
No doubt it was very frustrating for the engineers doing the work to
have their months of effort rejected, but it was also frustrating for
me, since I was trying make all parties aware of the impending rejection
well in advance.
As I said, it all ended up being an unfortunate timing of events with
unexpected side effects. At each instant of time it has always been
clear what to do ...
2005? We tried to set up a case for ROI for the support of a dmraid
plugin. I am merely a JAFO to that process trying to push it along.
Well, all your efforts are appreciated :)
Adaptec has an unfortunate history of simply not communicating well with
the Linux community -- and I note that's a two-way street. I've even
heard it whispered that Linux people "hate Adaptec", that we take some
sort of pleasure out of putting the screws to Adaptec.
Nothing could be further from the truth.
Exclusing you, Mark, who seems to understand this stuff, Adaptec just
seems to have a tough time understanding the rationale and goals behind
the feedback from SCSI and Linux maintainers.
Adaptec -- excluding aacraid -- continues to have a history of (a) being
grossly dissatisfied with the current SCSI code, and (b) concluding that
a proper solution simply works around all the problems. That's a fair
perspective, but Linux prefers the more cross-vendor approach of
modifying the base Linux code.
Greater than Linux itself, the GPL and open source create a commodity
effect: competitors work on the same piece of software, rather than
producing competing versions of software. Out of this principle falls
the "update SCSI core, don't workaround in your driver" approach. Ditto
for use of Device Mapper, rather than doing RAID in the driver itself,
or duplicating effort with EMD. With open source, code duplication just
increases effort, decreases test coverage, and increases the likelihood
of bugs.
The downside (from a vendor perspective) is that vendor engineers are
drafted into updating the Linux core, when a new spiffy hardware feature
needs to be supported. This is actually not a downside, but a benefit.
In the long run, common code is highly reus{able,ed}, leading to
rapid development, vastly increased test coverage, and maintainable even
if the original hardware vendor goes out of business, or EOLs the hardware.
I wish I could rewind the clock, and demonstrate to Justin, Scott, Luben
and other Adaptec engineers that there are solid reasons behind each of
these decisions, and its not "politics" or "NIH" or "we hate you" or "we
are the anointed ones, bow to us."
Linux doesn't have a roadmap, rather it has certain code patterns that
experience has taught us are sustainable, portable, and performant in
the long term. As long as new source code fits these code patterns, we
welcome the addition with open arms. From any company.
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
