mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Bill Davidsen <davidsen@tmr.com>, Jeff Garzik <jgarzik@pobox.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Martins Krikis <mkrikis@yahoo.com>,
	linux-kernel@vger.kernel.org, alan@lxorguk.ukuu.org.uk
Subject: Re: [ANNOUNCE] "iswraid" (ICHxR ataraid sub-driver) for 2.4.29
Date: Thu, 10 Feb 2005 18:33:39 -0200	[thread overview]
Message-ID: <20050210203339.GB20828@logos.cnet> (raw)
In-Reply-To: <58cb370e050210152820d6fc96@mail.gmail.com>


Hi Bart,

On Fri, Feb 11, 2005 at 12:28:04AM +0100, Bartlomiej Zolnierkiewicz wrote:

> > > [ 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 ?
> 
> It is worse than that - AFAIR iswraid provides some features which
> are NOT available in 2.6.x kernels. 

Oh really?

> > > 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.
> 
> Fully agreed but what is your point?  Mine was that we can different
> subsystems/drivers for the same device/functionality - like we have
> both IDE+siimage and libata+sata_sil drivers in 2.4.x.

My point is that the SATA subsystem is a very different case from 
device-mapper.

The SATA subsystem provides _hardware_ knowledge, it provides the ability 
for certain very popular devices to work, and improved functionality
for devices which could be driven by the IDE subsystem.

Now the device mapper can be thought of as a high-level abstraction in which 
LVM, RAID, and other functionality can be built on top of. We already have 
those in v2.4. 

They are quite different.

> Maybe Martins was forced to develop for ataraid in 2.4.x
> because lack of device-mapper.  In such case the current
> situations is our fault and we can learn something from it.

True. 

> > > 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.  



  reply	other threads:[~2005-02-11  0:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-29  1:15 Martins Krikis
2005-02-06  2:36 ` Jeff Garzik
2005-02-06  9:27   ` Arjan van de Ven
2005-02-06 12:45     ` Bartlomiej Zolnierkiewicz
2005-02-06 14:38       ` Jeff Garzik
2005-02-06 14:48         ` Christoph Hellwig
2005-02-06 14:49         ` Arjan van de Ven
2005-02-06 15:03           ` Jeff Garzik
2005-02-06 15:19             ` Bartlomiej Zolnierkiewicz
2005-02-10 19:35               ` Bill Davidsen
2005-02-10 20:05                 ` Bartlomiej Zolnierkiewicz
2005-02-10 22:04                   ` Bartlomiej Zolnierkiewicz
2005-02-10 18:39                     ` Marcelo Tosatti
2005-02-10 23:28                       ` Bartlomiej Zolnierkiewicz
2005-02-10 20:33                         ` Marcelo Tosatti [this message]
2005-02-11 10:46                       ` Arjan van de Ven
2005-02-06 15:28             ` Arjan van de Ven
2005-02-06 15:50             ` Christoph Hellwig
2005-02-06 16:09               ` Jeff Garzik
2005-02-06 16:27                 ` Christoph Hellwig
2005-02-07 16:45           ` Marcelo Tosatti
2005-02-07 18:29           ` Martins Krikis
     [not found]             ` <bc8bcc5105020711081f1de175@mail.gmail.com>
2005-02-07 19:30               ` Martins Krikis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050210203339.GB20828@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=bzolnier@gmail.com \
    --cc=davidsen@tmr.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkrikis@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®