linux-kernel - Re: [PATCH] libata: remove experimental tag on PATA drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091114001510.2dd0ab5d@lxorguk.ukuu.org.uk>
Date:	Sat, 14 Nov 2009 00:15:10 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	Robert Hancock <hancockrwd@...il.com>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	ide <linux-ide@...r.kernel.org>, Jeff Garzik <jgarzik@...ox.com>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] libata: remove experimental tag on PATA drivers

On Sat, 14 Nov 2009 00:46:29 +0100
Bartlomiej Zolnierkiewicz <bzolnier@...il.com> wrote:

> On Friday 13 November 2009 19:25:15 Alan Cox wrote:
> > > Fine but please update status of following host drivers that were
> > > marked as "stable" prematurely by commit e3389cb first:
> > > 
> > > PATA_PDC_OLD: needs to be marked as EXPERIMENTAL (or just BROKEN)
> > > - known reliability problems with UDMA
> > 
> > A few odd reports apparently linked to specific chip revs. It's at
> > least as stable as the old IDE one which doesn't work on my hardware. I'd
> 
> Skipping the technical merit of the quoted text for the moment -- I find

You mean the content ?

> the fact that you keep calling the present IDE host drivers (that many
> developers helped to fix) as "old" ones or "buggy" ones rather degrading

As you quoted the old PDC202xx driver does not work on my test hardware.
The libata one does. That is what is popularly known as a "fact". I'm not
entirely happy with either PDC driver for older chips and I've spent
considerable time grovelling through old drivers, alternate drivers and
what little documentation exists to try and figure it out in more detail.

The lost IRQ recovery patches seem to have helped a fair bit, and your
UDMA33 fix likewise.

> for their (this includes me of course) hard work.

All because you wouldn't work on the libata ones which had a future. You
are forgetting of course to mention that a good deal of analysis went
into deciding to switch to libata and teach libata to do PATA devices.
Stuff I'd say has proved to be bang on the mark as every PC class system
now has SATA, already has the SATA stack and in many cases have devices
where the PATA and SATA ports interact so must be driven by the same
stack. Now that CF is dying I'd say its pretty much proven the right
choice.

I am *really* glad to see that with the wireless you are contributing
heavily to both the old and new. If only you'd done that with PATA we
would all have been better off.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/