New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Sun, 21 Jun 2009 15:57:56 -0700 (PDT)

> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Mon, 22 Jun 2009 00:34:22 +0200
> 
>> Lets get over this quickly, since you seem to have such a great
>> insight into running IDE layer here is a little proposition..
>> 
>> ACK?  [ If not than can we please get back with the program? ]
> 
> Acked-by: David S. Miller <davem@davemloft.net>

I've created a new IDE development tree at:

	master.kernel.org:/pub/scm/linux/kernel/git/davem/ide-2.6.git

and the first patch is below.

I'll ask the patchwork folks to add an IDE group so we can manage
patches posted here.

I'm going to treat IDE as pure legacy, rather than as competition
with the PATA drivers which is what people whould be moving over to.

And more importantly I refuse to apply any driver patch that isn't
actually tested on said hardware.

ide: Take over as maintainer.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 MAINTAINERS |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1d47043..487aaea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2802,10 +2802,10 @@ S:	Supported
 F:	drivers/scsi/ips.*
 
 IDE SUBSYSTEM
-P:	Bartlomiej Zolnierkiewicz
-M:	bzolnier@gmail.com
+P:	David S. Miller
+M:	davem@davemloft.net
 L:	linux-ide@vger.kernel.org
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6.git
 S:	Maintained
 F:	Documentation/ide/
 F:	drivers/ide/
-- 
1.6.3.2

Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[Bartlomiej Zolnierkiewicz]

On Monday 22 June 2009 01:13:43 David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sun, 21 Jun 2009 15:57:56 -0700 (PDT)
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Date: Mon, 22 Jun 2009 00:34:22 +0200
> > 
> >> Lets get over this quickly, since you seem to have such a great
> >> insight into running IDE layer here is a little proposition..
> >> 
> >> ACK?  [ If not than can we please get back with the program? ]
> > 
> > Acked-by: David S. Miller <davem@davemloft.net>
> 
> I've created a new IDE development tree at:
> 
> 	master.kernel.org:/pub/scm/linux/kernel/git/davem/ide-2.6.git
> 
> and the first patch is below.
> 
> I'll ask the patchwork folks to add an IDE group so we can manage
> patches posted here.
> 
> I'm going to treat IDE as pure legacy, rather than as competition
> with the PATA drivers which is what people whould be moving over to.
> 
> And more importantly I refuse to apply any driver patch that isn't
> actually tested on said hardware.
> 
> ide: Take over as maintainer.

Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

You have my full support (don't hesitate to ping me if you need some
help) and I hope that the last few years of my of work would make your
job relatively easy and painless.

I would also like to use this occasion and thank all the people who
have been contributing to the project during my reign.  Thanks!!

> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  MAINTAINERS |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1d47043..487aaea 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2802,10 +2802,10 @@ S:	Supported
>  F:	drivers/scsi/ips.*
>  
>  IDE SUBSYSTEM
> -P:	Bartlomiej Zolnierkiewicz
> -M:	bzolnier@gmail.com
> +P:	David S. Miller
> +M:	davem@davemloft.net
>  L:	linux-ide@vger.kernel.org
> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6.git
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6.git
>  S:	Maintained
>  F:	Documentation/ide/
>  F:	drivers/ide/

Re: New IDE maintainer

[David Miller]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Mon, 22 Jun 2009 01:45:03 +0200

> You have my full support (don't hesitate to ping me if you need some
> help) and I hope that the last few years of my of work would make your
> job relatively easy and painless.
> 
> I would also like to use this occasion and thank all the people who
> have been contributing to the project during my reign.  Thanks!!

Thanks for all of your time and efforts over the years
Bart.

Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

Hi Dave, Bart,

On Sun, 21 Jun 2009 16:13:43 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: David Miller <davem@davemloft.net>
> Date: Sun, 21 Jun 2009 15:57:56 -0700 (PDT)
> 
> > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Date: Mon, 22 Jun 2009 00:34:22 +0200
> > 
> >> Lets get over this quickly, since you seem to have such a great
> >> insight into running IDE layer here is a little proposition..
> >> 
> >> ACK?  [ If not than can we please get back with the program? ]
> > 
> > Acked-by: David S. Miller <davem@davemloft.net>
> 
> I've created a new IDE development tree at:
> 
> 	master.kernel.org:/pub/scm/linux/kernel/git/davem/ide-2.6.git

So, do I immediately switch linux-next to this tree?  The current tree I
am using is empty (relative to Linus' tree).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: New IDE maintainer

[David Miller]

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 Jun 2009 10:00:21 +1000

>> I've created a new IDE development tree at:
>> 
>> 	master.kernel.org:/pub/scm/linux/kernel/git/davem/ide-2.6.git
> 
> So, do I immediately switch linux-next to this tree?  The current tree I
> am using is empty (relative to Linus' tree).

If there's nothing in Bart's tree currently, I don't see why not.

Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[Matthew Wilcox]

On Mon, Jun 22, 2009 at 01:45:03AM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Monday 22 June 2009 01:13:43 David Miller wrote:
> > From: David Miller <davem@davemloft.net>
> > Date: Sun, 21 Jun 2009 15:57:56 -0700 (PDT)
> > 
> > > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > > Date: Mon, 22 Jun 2009 00:34:22 +0200
> > > 
> > >> Lets get over this quickly, since you seem to have such a great
> > >> insight into running IDE layer here is a little proposition..
> > >> 
> > >> ACK?  [ If not than can we please get back with the program? ]
> > > 
> > > Acked-by: David S. Miller <davem@davemloft.net>
> > 
> > I'm going to treat IDE as pure legacy, rather than as competition
> > with the PATA drivers which is what people whould be moving over to.
> > 
> > And more importantly I refuse to apply any driver patch that isn't
> > actually tested on said hardware.
> > 
> > ide: Take over as maintainer.
> 
> Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> 
> You have my full support (don't hesitate to ping me if you need some
> help) and I hope that the last few years of my of work would make your
> job relatively easy and painless.
> 
> I would also like to use this occasion and thank all the people who
> have been contributing to the project during my reign.  Thanks!!

Thanks, Bart.

It isn't easy to be maintainer of a subsystem that is being obsoleted
by another.  It's even less easy to gracefully hand over maintenance,
as you have done.  Personally, I'd love it if you could contribute to
the ATA drivers in the future.  I think there are a number of ways they
could stand to be improved.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[Greg Freemyer]

> I'm going to treat IDE as pure legacy, rather than as competition
> with the PATA drivers which is what people whould be moving over to.

> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

What impact does that on Linux and its growing popularity in arm
platforms?  I had assumed that most arm platforms were long term users
of drivers/ide, but I have no facts to back that up.

Greg
-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[Jeff Garzik]

Greg Freemyer wrote:
>> I'm going to treat IDE as pure legacy, rather than as competition
>> with the PATA drivers which is what people whould be moving over to.
> 
>> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> What impact does that on Linux and its growing popularity in arm
> platforms?  I had assumed that most arm platforms were long term users
> of drivers/ide, but I have no facts to back that up.

libata already has several ARM drivers and does work on that platform in 
general.  A great many platforms are handled by the generic 
pata_platform driver.

There are a handful of IDE drivers not yet ported over to libata, all 
!x86 drivers; maybe there's an odd ARM platform or two in there, I 
haven't checked recently.

If there's a problem or missing functionality, just speak up...

	Jeff

Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[Alan Cox]

> There are a handful of IDE drivers not yet ported over to libata, all 
> !x86 drivers; maybe there's an odd ARM platform or two in there, I 
> haven't checked recently.

There are several drivers that are not supported in libata (and several
only in libata, and several that work better in one than the other for
reasons nobody can figure sometimes)

Biggest legacy hanger on is the older PowerMac boxes because both people
who planned to do the driver had the mac they were using simply die of
old age on them.

sgiioc4 is another obvious "modern machine" case. The rest are pretty
obscure (eg mac68K drivers and IDE VLB drivers most of which don't
actually work in the old IDE code even though there is code)

Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[Arnd Bergmann]

On Monday 22 June 2009, Alan Cox wrote:
> sgiioc4 is another obvious "modern machine" case. The rest are pretty
> obscure (eg mac68K drivers and IDE VLB drivers most of which don't
> actually work in the old IDE code even though there is code)

Actually, m68k, m32r and h8300 currently can't use libata at all
for one reason or another, mostly missing support for dma-mapping.h

Microblaze and the upcoming S+Core also lack DMA support right
now, but that should get rectified soon.

You could argue that still all of these fall into the 'obscure'
category, of course. With just a little effort on the architecture
side, it should be possible to convert almost any non-PCI ATA
chip to use drivers/ata/pata_platform.c or pata_of_platform.c.

	Arnd <><

Re: New IDE maintainer (was Re: cmd64x: irq 14: nobody cared - system is dreadfully slow)

[Alan Cox]

> Actually, m68k, m32r and h8300 currently can't use libata at all
> for one reason or another, mostly missing support for dma-mapping.h

That wants fixing and your ifdef patches looked a route to beat it into
some kind of shape

> side, it should be possible to convert almost any non-PCI ATA
> chip to use drivers/ata/pata_platform.c or pata_of_platform.c.

The ioc4 and the ppc ones are a bit harder as they have custom DMA
descriptor tables and stuff. The rest I agree.