On Mon, Dec 05, 2005 at 01:06:41PM -0800, Darrick J. Wong wrote: > 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. Very good. Looking forward to your contribution to dmraid. > > Is linux-lvm the appropriate place for dmraid patches/discussion? I > couldn't find any mailing lists that sounded more appropriate. ataraid-list@xxxxxxxxxx for dmraid. dm-devel for device-mapper. Regards, Heinz -- The LVM Guy -- > > --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 *** Software bugs are stupid. Nevertheless it needs not so stupid people to solve them *** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Red Hat GmbH Consulting Development Engineer Am Sonnenhang 11 Cluster and Storage Development 56242 Marienrachdorf Germany Mauelshagen@xxxxxxxxxx +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - : 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
