Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Stan Cunningham]

Bartlomiej Zolnierkiewicz wrote:
> > the IDE code today, when we have libata around which is a much better 
> > code base to work from? I'm afraid it still escapes me. I don't mean to 
> 
> Simply:
> 
> * Not all hardware is supported by libata.

Then it would be best to port that hardware from ide to libata. Make a page on http://ata.wiki.kernel.org listing every single functionality that is present in ide but missing from libata, and then start tackling the points one by one. A lot of these points were discussed in this thread:

http://marc.info/?t=121777915500001&r=1&w=2

Go through the ide drivers with a fine tooth comb and make sure all the quirks and PCI IDs are transfered to the corresponding libata driver.

It seems that Bart, Boris and the other recent ide contributors care a lot about old hardware, which is great because the corporate-sponsored libata developers are paid to focus on new hardware. You should in theory complement each other well, but please work on the same codebase so that the optimizations one group makes to the framework help everybody.

> * Today's IDE code is not so different from libata's.

All the more reason porting missing functionality to libata should be easier.

> * I'm much more familiar with IDE's code than libata's. :)

Sorry, but that's a bad excuse. If you want your work to reach and help the greatest number of people, you should work on improving libata because that  is what the vast majority of developers are working to optimize. Porting old hardware to libata will allow that old hardware to take advantage of many of optimizations and new features that the libata framework already provides! 

I know many distros still use ide for CD drives, but that *sucks* for users because the two driver frameworks loaded simultaneously waste memory and step on each other's toes. Plus, obscure fixes to one framework will not help the other, so users have to stumble on the same bug *twice* before it's fixed for good. But most likely it will get fixed in one framework and overlooked in the other.

So please, take the time to overcome the libata learning curve and start systematically porting support for the remaining old hardware to libata.

Stan


      

Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Alan Cox]

> It seems that Bart, Boris and the other recent ide contributors care a lot about old hardware, which is great because the corporate-sponsored libata developers are paid to focus on new hardware.

***Parp***

sorry thats completely bogus: Libata supports more prehistoric pointless
ISA and VLB controllers than drivers/ide. Not that it matters as every
vendor I know of ships Libata and ships with the ISA/VLB stuff disabled 8)

Alan

Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Bartlomiej Zolnierkiewicz]

On Monday 13 October 2008, Stan Cunningham wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > > the IDE code today, when we have libata around which is a much better 
> > > code base to work from? I'm afraid it still escapes me. I don't mean to 
> > 
> > Simply:
> > 
> > * Not all hardware is supported by libata.
> 
> Then it would be best to port that hardware from ide to libata. Make a page on http://ata.wiki.kernel.org listing every single functionality that is present in ide but missing from libata, and then start tackling the points one by one. A lot of these points were discussed in this thread:
> 
> http://marc.info/?t=121777915500001&r=1&w=2
> 
> Go through the ide drivers with a fine tooth comb and make sure all the quirks and PCI IDs are transfered to the corresponding libata driver.
> 
> It seems that Bart, Boris and the other recent ide contributors care a lot about old hardware, which is great because the corporate-sponsored libata developers are paid to focus on new hardware. You should in theory complement each other well, but please work on the same codebase so that the optimizations one group makes to the framework help everybody.
> 
> > * Today's IDE code is not so different from libata's.
> 
> All the more reason porting missing functionality to libata should be easier.
> 
> > * I'm much more familiar with IDE's code than libata's. :)
> 
> Sorry, but that's a bad excuse. If you want your work to reach and help the greatest number of people, you should work on improving libata because that  is what the vast majority of developers are working to optimize. Porting old hardware to libata will allow that old hardware to take advantage of many of optimizations and new features that the libata framework already provides! 
> 
> I know many distros still use ide for CD drives, but that *sucks* for users because the two driver frameworks loaded simultaneously waste memory and step on each other's toes. Plus, obscure fixes to one framework will not help the other, so users have to stumble on the same bug *twice* before it's fixed for good. But most likely it will get fixed in one framework and overlooked in the other.

It is not mine fault.  Please complain to the right people.

You may want to dig into archives and learn about history of libata.
Especially under what conditions it has been ACK-ed and merged _five_
years ago.  Just to quickly recall, there were two such conditions:

* PATA support would be moved from IDE to libata in an evolutionary way.

  Didn't happen.  Instead we had code split, loss of git history, user
  confusion and unimaginable waste of time/resources (quick stunt trick
  and more then three long years of rediscovering the wheel...).

* It would be moved out of SCSI in the long-term.

  Didn't happen.  Five years is more than enough time for that.

> So please, take the time to overcome the libata learning curve and start systematically porting support for the remaining old hardware to libata.

I don't mind somebody doing it.

I just have zero motivation to do it myself in my private time.

PS It is not like I don't know the libata's code completely... ;)

Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Alan Cox]

O> You may want to dig into archives and learn about history of libata.
> Especially under what conditions it has been ACK-ed and merged _five_
> years ago.  Just to quickly recall, there were two such conditions:
> 
> * PATA support would be moved from IDE to libata in an evolutionary way.

IDE stood stale for a year while you vanished (to CERN ?) so the rest of
the world decided to get on with it. As it happens an evolutionary change
would have made no sense as the mentality of the code is [thankfully]
quite different and we could eject an enormous amount of crud in the
process.

> * It would be moved out of SCSI in the long-term.
> 
>   Didn't happen.  Five years is more than enough time for that.

Its mostly happened, there are some interactions that still slowly push
their way up into the block layer.
 
> > So please, take the time to overcome the libata learning curve and start systematically porting support for the remaining old hardware to libata.
> 
> I don't mind somebody doing it.
> 
> I just have zero motivation to do it myself in my private time.

Yeah - I'm slowly working on it in parallel with the tty code.
Unfortunately the big remaining one (mac support) didn't happen as the
Mac that dwmw2 loaned me died and as in typical crapple design style it
needed major surgery with sharpened wall paper scrapers to even open it
the work didn't get done.

For non mainstream systems I'm in no great hurry to move them to libata,
its not like a Commode Amiga is a serious platform that needs the latest
cutting edge code.

Alan

Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Stan Cunningham]

--- On Mon, 10/13/08, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Libata supports more prehistoric pointless
> ISA and VLB controllers than drivers/ide.

Perhaps, but the ultimate goal for libata should be to support *all* the hardware that works under drivers/ide. Until that's achieved, drivers/ide is still needed despite the drawbacks of having two frameworks.

> Unfortunately the big remaining one (mac support)
> didn't happen as the
> Mac that dwmw2 loaned me died and as in typical crapple
> design style it
> needed major surgery with sharpened wall paper scrapers to
> even open it
> the work didn't get done.

I started a wiki page ( http://ata.wiki.kernel.org/index.php/Hardware_For_Developers ) where developers can list the hardware they need in order to develop libata drivers. I'm sure there are people with unused hardware that they would be be willing to donate to interested developers. Or give money donations so that developers can buy the necessary hardware. Please feel free to add the Apple parts you need to that page.

BTW, I recall there was another attempt at writing a libata driver for Apple hardware, namely pata_macio by Benjamin Herrenschmidt.

Stan


      

Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Mikael Pettersson]

Stan Cunningham writes:
 > > Unfortunately the big remaining one (mac support)
 > > didn't happen as the
 > > Mac that dwmw2 loaned me died and as in typical crapple
 > > design style it
 > > needed major surgery with sharpened wall paper scrapers to
 > > even open it
 > > the work didn't get done.
 > 
 > I started a wiki page ( http://ata.wiki.kernel.org/index.php/Hardware_For_Developers ) where developers can list the hardware they need in order to develop libata drivers. I'm sure there are people with unused hardware that they would be be willing to donate to interested developers. Or give money donations so that developers can buy the necessary hardware. Please feel free to add the Apple parts you need to that page.
 > 
 > BTW, I recall there was another attempt at writing a libata driver for Apple hardware, namely pata_macio by Benjamin Herrenschmidt.

I tried pata_macio in a G4 eMac. Worked fine, except that something was
missing in sysfs or OF or whereever causing yaboot to fail to update the
boot loader while that disk was driven by pata_macio.

So I put it on ice waiting for newer versions from Ben, but that never
happened so I forgot about it.

Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Alan Cox]

On Mon, 13 Oct 2008 19:11:04 -0700 (PDT)
Stan Cunningham <stan.cunningham@yahoo.com> wrote:

> --- On Mon, 10/13/08, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > Libata supports more prehistoric pointless
> > ISA and VLB controllers than drivers/ide.
> 
> Perhaps, but the ultimate goal for libata should be to support *all* the hardware that works under drivers/ide. Until that's achieved, drivers/ide is still needed despite the drawbacks of having two frameworks.

I don't have a problem having two frameworks, one of which is just used
by things like the commode amiga and other ancient relics. If one of the
tiny number of users of the port wants libata they can probably port it
over in a few minutes and then spend a week recompiling ;)

> BTW, I recall there was another attempt at writing a libata driver for Apple hardware, namely pata_macio by Benjamin Herrenschmidt.

Yes Ben is working on this stuff now

Alan

Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Bartlomiej Zolnierkiewicz]

On Tuesday 14 October 2008, Alan Cox wrote:
> O> You may want to dig into archives and learn about history of libata.
> > Especially under what conditions it has been ACK-ed and merged _five_
> > years ago.  Just to quickly recall, there were two such conditions:
> > 
> > * PATA support would be moved from IDE to libata in an evolutionary way.
> 
> IDE stood stale for a year while you vanished (to CERN ?) so the rest of

The real issue is that some corporate people are taking things for granted
so when the pace slowed down (after I "vanished", which was a known fact,
and had a less of my time than before to work on IDE) they started pushing
more pressure on me instead of considering constructive solutions, i.e.
it is not like I ever got an offer from somebody else to take over the code
or to help with the code etc.

[ It is also worth to notice that I never promised to be the one doing
  all the IDE -> libata work so if somebody thought otherwise it was only
  his unrealistic expectation (especially given timescale and the fact
  that because of 2.5.x IDE revert, early 2.4.x -> 2.6.x IDE stabilization
  required a lot work). ]

Yes, the code "stood stale" but only after flamewar + libata PATA + kick
from some fellow maintainers (well, I learned that the outcome of the game
has already been decided months ago and thought that me vs Red Hat was a
lost cause + also that I was a real idiot from the start :-).

[ "stood stale" is not completely correct since the patches were
  being (slowly) reviewed and Andrew has been pushing them upstream ]

> the world decided to get on with it. As it happens an evolutionary change
> would have made no sense as the mentality of the code is [thankfully]

It is not like there wasn't a sane roadmap, TODOs, repeated descriptions
of needed tasks, just nobody from corporate Linux world was interested in
doing any real work (except Tejun).  This wasn't so bad in itself because
I would still be able to handle most of it.  The real problem was that
I was forwarded unprocessed bugreports or half-baked patches and actually
expected/pressed to also handle all that at the same time.  While there
were absolutely no people around to help with it.

> quite different and we could eject an enormous amount of crud in the
> process.

I think that there is no point in discussing it any further since we are
unlikely to ever come to similar conclusions.

Lets just peacefully disagree on this case and move on other things.

Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Stan Cunningham]

--- On Mon, 10/13/08, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > I know many distros still use ide for CD drives, but
> > that *sucks* for users because the two driver frameworks
> > loaded simultaneously waste memory and step on each
> > other's toes. Plus, obscure fixes to one framework will
> > not help the other, so users have to stumble on the same bug
> > *twice* before it's fixed for good. But most likely it
> > will get fixed in one framework and overlooked in the other.
> 
> It is not mine fault.  Please complain to the right people.
> 
> You may want to dig into archives and learn about history
> of libata.
> Especially under what conditions it has been ACK-ed and
> merged _five_
> years ago.  Just to quickly recall, there were two such
> conditions:
> 
> * PATA support would be moved from IDE to libata in an
> evolutionary way.
> 
>   Didn't happen.  Instead we had code split, loss of
> git history, user
>   confusion and unimaginable waste of time/resources (quick
> stunt trick
>   and more then three long years of rediscovering the
> wheel...).

I guess you're right that maintaining the continuity of code would have been useful. But ide drivers can still be used as a reference when creating or improving libata drivers. I don't think that git would have been of much use given that it was created only in 2005 and any previous code changes don't appear in its history.

But previous mistakes can't be undone. Let's consider what is the most productive approach for the future, given today's situation.

> > So please, take the time to overcome the libata
> learning curve and start systematically porting support for
> the remaining old hardware to libata.
> 
> I don't mind somebody doing it.

I'm sorry to hear that, because as I see it, porting the remaining hardware and quirks to libata would benefit end users more than dragging along two frameworks. 

> I just have zero motivation to do it myself in my private
> time.

I certainly wish companies would hire more developers to focus on doing this tedious but much needed work.

Stan