From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: stan.cunningham@yahoo.com
Cc: linux-ide@vger.kernel.org
Subject: Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)
Date: Mon, 13 Oct 2008 23:45:51 +0200 [thread overview]
Message-ID: <200810132345.51836.bzolnier@gmail.com> (raw)
In-Reply-To: <678468.92529.qm@web57414.mail.re1.yahoo.com>
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... ;)
next prev parent reply other threads:[~2008-10-13 21:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-13 19:46 Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements) Stan Cunningham
2008-10-13 20:24 ` Alan Cox
2008-10-13 21:45 ` Bartlomiej Zolnierkiewicz [this message]
2008-10-13 22:46 ` Alan Cox
2008-10-14 2:11 ` Stan Cunningham
2008-10-14 8:05 ` Mikael Pettersson
2008-10-14 9:01 ` Alan Cox
2008-10-14 2:11 ` Bartlomiej Zolnierkiewicz
2008-10-14 2:04 ` Stan Cunningham
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=200810132345.51836.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=stan.cunningham@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.