On Thu, Feb 10, 2005 at 11:04:09PM +0100, Bartlomiej Zolnierkiewicz wrote: > On Thu, 10 Feb 2005 21:05:13 +0100, Bartlomiej Zolnierkiewicz > <[EMAIL PROTECTED]> wrote: > > On Thu, 10 Feb 2005 14:35:23 -0500, Bill Davidsen <[EMAIL PROTECTED]> wrote: > > > Bartlomiej Zolnierkiewicz wrote: > > > > On Sun, 06 Feb 2005 10:03:27 -0500, Jeff Garzik <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > >>Arjan van de Ven wrote: > > > >> > > > >>>>I consider it not a new feature, but a missing feature, since > > > >>>>otherwise > > > >>>>user data cannot be accessed in the RAID setups. > > > >>> > > > >>> > > > >>>the same is true for all new hardware drivers and hardware support > > > >>>patches. And for new DRM (since new X may need it) and new .. and > > > >>>new ... where is the line? > > > >>> > > > >>>for me a deep maintenance mode is about keeping existing stuff working; > > > >>>all new hw support and derivative hardware support (such as this) can > > > >>>be > > > >>>pointed at the new stable series... which has been out for quite some > > > >>>time now.. > > > >> > > > >>Red herring. > > > >> > > > >>2.4.x has ICH5/6 support -- but is missing the RAID support component. > > > >> > > > >>We are talking about hardware that is ALREADY supported by 2.4.x kernel, > > > >>not new hardware. > > > >> > > > >>We are also talking about inability to access data on hardware supported > > > >>by 2.4.x, not something that can easily be ignored or papered over with > > > >>a compatibility mode. > > > > > > > > > > > > the same arguments can be used for crypto support etc., > > > > answer is - use 2.6.x or add extra patches to get 2.4.x working > > > > > > It's fix in a sense. The hardware is supported now, just not very well. > > > If an IDE chipset was capable of UDA4 and the driver only allowed UDA2 > > > it would be a fix, in this case thehardware is supported partially, the > > > RAID conponent isn't working, and this is the fix. > > > > The so called "RAID component" is 100% *software* solution. > > > > BTW What is UDA? > > [ This mail is just to explain why I don't like iswraid, > I don't care if it gets merged that much... ] > > another BTW: this driver adds another incompatibility between > 2.4.x and 2.6.x.
What do you mean "adds another incompatibility" ? That users will have to switch to dmraid when upgrading to v2.6.x ? > Also most 2.4.x users will want (or have to) migrate > to 2.6.x one day and they will have to switch to using device mapper > and dmraid anyway. From my POV merging/supporting iswraid > in any way is a lost of time for EVERYBODY in the long-term. > Martins, I appreciate all hard work that went into iswraid driver but > please face the simple fact, this driver was already obsoleted in > the moment it was created (from Linux development process POV). > > I previously (October?) asked about merging device-mapper > instead as it provides easier way to migrate to 2.6.x (not only for > Intel "RAID component" users but for ALL "RAID components" users) > as they would be able to use the same method for accessing their > data in both kernels. I was said that it is too late for such changes > (I consider device-mapper a new driver, changes to existing code > are REALLY minimal AFAIR) and that 2.4.x should stick to ataraid while > 2.6.x to device-mapper which was just silly argument IMHO (why we > don't stick to IDE drivers for SATA in 2.4.x?). SATA is not the same case as sw-RAID in my POV Bart, it allows many users to be _able_ use SATA controllers/drives. > I finally gave up because I didn't want to waste more my time on this and > didn't want to go into > politics etc... but damn iswraid wasn't merged so I feel stupid now. :-) Good to hear your opinion. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
