All, At last, I've been given the go-ahead to work on hostraid support for dmraid. I'll post some patches when I've made some progress. Is linux-lvm the appropriate place for dmraid patches/discussion? I couldn't find any mailing lists that sounded more appropriate. --D Jeff Garzik wrote: > 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
