libata: remove experimental tag on PATA drivers
PATCH 1/1 libata: remove experimental tag on PATA drivers
Remove the experimental tag on Parallel ATA drivers. Though some of the individual PATA drivers are still marked as experimental, as a group they can hardly be considered to be, given they've been used in various distros for some time.
drivers/ata/Kconfig +1 -1
@@ -3,7 +3,7 @@ # menuconfig ATA - tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers" + tristate "Serial ATA and Parallel ATA drivers" depends on HAS_IOMEM depends on BLOCK depends on !(M32R || M68K) || BROKEN
Quoted 6 lines · On Thu, 12 Nov 2009 20:13:40 -0600 Robert Hancock <[email protected]> wrote:
Remove the experimental tag on Parallel ATA drivers. Though some of the individual PATA drivers are still marked as experimental, as a group they can hardly be considered to be, given they've been used in various distros for some time.
Signed-off-by Robert Hancock <[email protected]>
And we should probably thin down the EXPERIMENTALs in the drivers too. I'll take a look at those in a bit
Quoted 6 lines · On Friday 13 November 2009 03:13:40 Robert Hancock wrote:
Remove the experimental tag on Parallel ATA drivers. Though some of the individual PATA drivers are still marked as experimental, as a group they can hardly be considered to be, given they've been used in various distros for some time.
Signed-off-by Robert Hancock <[email protected]>
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
PATA_ALI: EXPERIMENTAL
- ATAPI DMA is still broken
PATA_CMD64X: EXPERIMENTAL
- potential data corruption issues remains unfixed for CMD64[3,6]
PATA_SIS: EXPERIMENTAL
- missing MWDMA support on newer controllers
They are all old & known problems and not present in [ "old", "deprecated", "legacy" ] counterparts.
Quoted 13 lines
drivers/ata/Kconfig +1
-1@@ -3,7 +3,7 @@ # menuconfig ATA - tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers" + tristate "Serial ATA and Parallel ATA drivers" depends on HAS_IOMEM depends on BLOCK depends on !(M32R || M68K) || BROKEN
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 5 lines
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 love to get it working on everything but neither driver does and I don't think we are likely to ever extract more docs from Promise.
Quoted 2 lines
PATA_ALI: EXPERIMENTAL
- ATAPI DMA is still broken
Not experimental as we default to not doing ATAPI DMA. Glancing over the code I notice the ALI C2/C3 workaround probably wants adding to the old driver as it can do nasty things otherwise. (See the reset function in the pata_ali driver)
Quoted 2 lines
PATA_CMD64X: EXPERIMENTAL
- potential data corruption issues remains unfixed for CMD64[3,6]
Patch in testing, and unlike the old IDE one it doesn't cripple the controller but implements the proper workaround in full including permitting parallel PIO command streams. I'll push that back through stable once done.
Quoted 2 lines
PATA_SIS: EXPERIMENTAL
- missing MWDMA support on newer controllers
Yes seems someone fixed that in the old driver but didn't forward port it. Trivial and fixed.
BTW - its wrong in the old driver as far as I can see - it doesn't clip the DMA mode to the PIO limit as required by the documentation and the ATA standard. Remember the same timings are used for both PIO and MWDMA cycles.
Quoted 2 lines
They are all old & known problems and not present in [ "old", "deprecated", "legacy" ] counterparts.
Which has its own different set of problems.
Any others spring to mind while you are at it ?
Alan
Quoted 10 lines · On Friday 13 November 2009 19:25:15 Alan Cox wrote:
Quoted 5 lines
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 UDMAA 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 love to get it working on everything but neither driver does and I don't think we are likely to ever extract more docs from Promise.
"A few odd reports..." is a big understatement here..
Quoted 4 lines
Quoted 2 lines
PATA_ALI: EXPERIMENTAL
- ATAPI DMA is still brokenNot experimental as we default to not doing ATAPI DMA. Glancing over the
Which is a regression compared to the "old IDE" driver.
Quoted 3 lines
code I notice the ALI C2/C3 workaround probably wants adding to the old driver as it can do nasty things otherwise. (See the reset function in the
pata_alidriver)
Please let the driver's maintainer know about it.
One would wonder why workaround hasn't been back-ported to stable driver but said one is not familiar with kernel development process' definitions of such words as "progress", "working with", "consensus" and "technical honesty".
Quoted 7 lines
Quoted 2 lines
PATA_CMD64X: EXPERIMENTAL
- potential data corruption issues remains unfixed for CMD64[3,6]Patch in testing, and unlike the old IDE one it doesn't cripple the controller but implements the proper workaround in full including permitting parallel PIO command streams. I'll push that back through stable once done.
This patch is way too complex and risky for -rc, let alone -stable.
Quoted 4 lines
Quoted 2 lines
PATA_SIS: EXPERIMENTAL
- missing MWDMA support on newer controllersYes seems someone fixed that in the old driver but didn't forward port
You mean like someone fixed the non-experimental driver back in October 2007 and the author of the experimental one didn't care to port over the fix for two years?
Indeed a very bad thing and much worse than not porting back fixes from experimental stuff to a stable code. As the author of the original fix I would like to stand corrected and publicly apologize for my negligence.
Quoted 1 line
it. Trivial and fixed.
I can't see a fix anywhere but I'll assume that I can't look for it properly (I'm really sorry for it).
Quoted 4 lines
BTW - its wrong in the old driver as far as I can see - it doesn't clip the DMA mode to the PIO limit as required by the documentation and the ATA standard. Remember the same timings are used for both PIO and MWDMA cycles.
Please let the driver's maintainer know.
Quoted 4 lines
Quoted 2 lines
They are all old & known problems and not present in [ "old", "deprecated", "legacy" ] counterparts.
Which has its own different set of problems.
Which doesn't matter at all here.
Progress is not about replacing one set of slightly buggy drivers with another slightly buggy one. At least this was the old definition of the word..
Quoted 1 line
Any others spring to mind while you are at it ?
HPA handling related patches that were "being worked on" if you really would like to know..
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 3 lines
Quoted 1 line
Not experimental as we default to not doing ATAPI DMA. Glancing over the
Which is a regression compared to the "old IDE" driver.
And given the two drivers show the difference when exactly the sequence of I/O writes/reads occurs one that nobody plans to worry about as its clearly some kind of hardware timing issue.
Quoted 7 lines
Quoted 3 lines
code I notice the ALI C2/C3 workaround probably wants adding to the old driver as it can do nasty things otherwise. (See the reset function in the
pata_alidriver)Please let the driver's maintainer know about it.
One would wonder why workaround hasn't been back-ported to stable driver
It's in the stable driver, might not be in drivers/ide. The note about it being missing was posted out to various people at the time so I guess it got missed
Quoted 9 lines
Quoted 7 lines
Quoted 2 lines
PATA_CMD64X: EXPERIMENTAL
- potential data corruption issues remains unfixed for CMD64[3,6]Patch in testing, and unlike the old IDE one it doesn't cripple the controller but implements the proper workaround in full including permitting parallel PIO command streams. I'll push that back through stable once done.
This patch is way too complex and risky for -rc, let alone -stable.
How would you know - I've not posted it yet ? And btw I don't plan to post it for the -rc. Nor would simply posting a serializing hack fix it. It might make it less likely to occur but that isn't a fix.
Quoted 4 lines
Quoted 1 line
it. Trivial and fixed.
I can't see a fix anywhere but I'll assume that I can't look for it properly (I'm really sorry for it).
Fixed as in I fixed it now. Which is why I just noticed the old IDE ones are buggy. I'll add it to the next patch sets for Jeff, along with the Toshiba driver and some other bits.
Alan
Quoted 11 lines · On Friday 13 November 2009 22:30:07 Alan Cox wrote:
Quoted 9 lines
Quoted 7 lines
Quoted 2 lines
PATA_CMD64X: EXPERIMENTAL
- potential data corruption issues remains unfixed for CMD64[3,6]Patch in testing, and unlike the old IDE one it doesn't cripple the controller but implements the proper workaround in full including permitting parallel PIO command streams. I'll push that back through stable once done.
This patch is way too complex and risky for -rc, let alone -stable.
How would you know - I've not posted it yet ? And btw I don't plan to
I prefer to not talk about "virtual" patches (especially since I'm still waiting for HPA fixes promised in May) and the only patch so far was the one from two weeks ago:
http://article.gmane.org/gmane.linux.ide/43136
[ it has still unfixed problems.. ]
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 4 lines
http://article.gmane.org/gmane.linux.ide/43136[ it has still unfixed problems.. ]
Which of course you haven't bothered to point out or explain.
Quoted 6 lines · On Friday 13 November 2009 23:42:51 Alan Cox wrote:
Quoted 4 lines
http://article.gmane.org/gmane.linux.ide/43136[ it has still unfixed problems.. ]
Which of course you haven't bothered to point out or explain.
I meant problems reported by Mikulas:
http://thread.gmane.org/gmane.linux.ide/43069/focus=43136
Maybe they were fixed in your local tree but how would anyone know that given that there haven't been any updates on the problem for the last two weeks..
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 6 lines · On Fri, 13 Nov 2009 23:58:45 +0100 Bartlomiej Zolnierkiewicz…
Quoted 5 lines · On Friday 13 November 2009 23:42:51 Alan Cox wrote:
Quoted 4 lines
http://article.gmane.org/gmane.linux.ide/43136[ it has still unfixed problems.. ]
Quoted 8 lines
Quoted 1 line
Which of course you haven't bothered to point out or explain.
I meant problems reported by Mikulas:
http://thread.gmane.org/gmane.linux.ide/43069/focus=43136Maybe they were fixed in your local tree but how would anyone know that given that there haven't been any updates on the problem for the last two weeks..
Yeah its fixed - well I think so. I've not chased it up further yet because I've been working on far more important things than an anicent IDE controller patch that isn't an -rc candidate anyway.
(basically you need to also set priv->dma_live if you are the only device or nothing is live but doing DMA)
Alan
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line
Any others spring to mind while you are at it ?
HPA handling related patches that were "being worked on" if you really would like to know..
Can you elaborate on this one?
Thanks for posting all these issues to linux-ide, and getting them discussed. It is appreciated.
Jeff
Quoted 8 lines · On Friday 13 November 2009 22:57:51 Jeff Garzik wrote:
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Quoted 1 line
Any others spring to mind while you are at it ?
HPA handling related patches that were "being worked on" if you really would like to know..
Can you elaborate on this one?
Certain someone announced that he was working on porting my IDE HPA work to libata, after almost half a year there is nothing out of it and all my queries regarding the status of said work are ignored..
I begin to assume that such announcement was just a well planned strategy to put stop to my (then ongoing) attempts in reaching other libata developers in helping me with porting the code..
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 8 lines · El Fri, 13 Nov 2009 18:25:15 +0000 Alan Cox <[email protected]> escribió:
Quoted 3 lines
PATA_ALI: EXPERIMENTAL
- ATAPI DMA is still brokenNot experimental as we default to not doing ATAPI DMA. Glancing over the code I notice the ALI C2/C3 workaround probably wants adding to the old driver as it can do nasty things otherwise. (See the reset function in the
pata_alidriver)
FWIW I have a Motherboard with Ali chipset and have been using ATAPI DMA
(forcing it via proc) without issues since the DMA was disabled by default.
lspci -v
IDE interface: ALi Corporation M5229 IDE (rev c7) (prog-if 8a [Master SecP PriP])
Subsystem: ASRock Incorporation Device 5229
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 21 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at ff00 [size=16]
Capabilities: <access denied>
Kernel driver in use: pata_ali
Kernel modules: ata_generic
Quoted 4 lines
Alan
Quoted 8 lines · On Friday 13 November 2009 19:25:15 Alan Cox wrote:
Quoted 5 lines
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 UDMAA 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 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 for their (this includes me of course) hard work.
Especially given your complete lack of familiarity with post-2004 changes.
See for yourself, *50* mostly _trivial_ patches during *5* years:
[ "git log --follow --since="5 years ago" drivers/ide|grep "Author: Alan Cox" -B1 -A3"
output edited for easier reading ]
commit d878829 piix: The Sony TZ90 needs the cable type hardcoding
commit ccd32e2 ide: Switch to a common address
commit 1bee4d1 pdc202xx_old: remove surplus initialiser
commit d3bad45 dtc2278: note on docs
commit 9702b5d ide: Stop mapping ROMs
commit 7859557 ide: Fix a theoretical Ooops case
commit 2074a10 ide/pci/serverworks.c: Fix corruption/timeouts with MegaIDE commit 640b31b sl82c105: Switch to ref counting API commit 846c11a ide: remove a ton of pointless #undef REALLY_SLOW_IO commit 8693d3e siimage: DRAC4 note commit fdb77da ide-floppy: Fix unformatted media crash commit 3e9e4c8 ide/generic: Jmicron has its own drivers now commit ee2f344 [PATCH] ide-cd: Handle strange interrupt on the Intel ESB2 commit 6451956 [PATCH] ide: complete switch to pci_get commit b148900 [PATCH] ide: more conversion to pci_get APIs commit 23a1b2a [PATCH] via82cxxx: handle error condition properly commit c333526 [PATCH] JMB 368 PATA detection commit 3a42bb2 [PATCH] ide: add sanity checking to ide taskfile ioctl commit 3719bc5 [PATCH] ide-generic: jmicron fix commit 652aa16 [PATCH] IDE: more pci_find cleanup commit 913759a [PATCH] ide: Fix crash on repeated reset commit 5ac2469 [PATCH] ide: backport piix fixes from libata into the legacy.. commit bbb3bbd [PATCH] non-libata driver for Jmicron devices commit 40cddf2 [PATCH] sis5513: Switch to pci refcounting commit 970a613 [PATCH] serverworks: Switch to pci refcounted interfaces commit 1424e50 [PATCH] piix: Use refcounted interface when searching for a .. commit 28a2a3f [PATCH] Fix 2.6.18-rc6 IDE breakage, add missing ident neede.. commit a7dec1e [PATCH] Missing PCI id update for VIA IDE commit 79860a9 [PATCH] PATCH: 2.6.18 oops on boot fix for IDE commit 15e0c69 [PATCH] ide: fix Jmicron support commit faab17b [PATCH] Fix problem with ATAPI DMA on IT8212 in Linux commit 3706a87 [PATCH] Set err_stops_fifo for newer Promise as well commit 57e834e [PATCH] ide: clean up pdc202xx_old so its more readable (don.. commit f201f50 [PATCH] ide: housekeeping on IDE drivers commit da574af [PATCH] ide: fix error handling for drives which clear the F.. commit 2930d1b [PATCH] SC1200 debug printk commit 19c1ef5 [PATCH] ide: clean up siimage commit 1a1276e [PATCH] Old IDE, fix SATA detection for cabling commit 4fb0f76 [PATCH] Fix IDE locking error commit dbe217a [PATCH] IDE CD end-of media error fix commit d266ab8 [PATCH] Small fixes backported to old IDE SiS driver commit 0c866b5 [PATCH] ide: set latency when resetting it821x out of firmwa.. commit d7d7634 [PATCH] ide: clean up the garbage in eighty_ninty_three commit da9091e [PATCH] ide: it8212 backport for Bartlomiej IDE commit bb732d7 [PATCH] ide: fix crashes with hotplug serverworks commit b39b01f [PATCH] ide: fix the HPT366 driver layer commit b189346 [PATCH] ide: ide-generic, allow for capture of other unsuppo.. commit 68ad991 [PATCH] ide: IDE timing violation on reset commit 58ecd15 [PATCH] ide: samsung SN-124 works perfectly well with DMA commit 6efd936 [PATCH] ide: fix ide-disk inability to handle LBA only devic..
Despite this it seems that at least LWN.net seems to treat your opinions with completely undeserved seriousness.. Weird.
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 11 lines · On Sat, 14 Nov 2009 00:46:29 +0100 Bartlomiej Zolnierkiewicz…
Quoted 8 lines · On Friday 13 November 2009 19:25:15 Alan Cox wrote:
Quoted 5 lines
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 UDMAA 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 ?
Quoted 2 lines
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.
Quoted 1 line
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
Quoted 15 lines · On Saturday 14 November 2009 01:15:10 Alan Cox wrote:
Quoted 11 lines · On Sat, 14 Nov 2009 00:46:29 +0100 Bartlomiej Zolnierkiewicz…
Quoted 8 lines · On Friday 13 November 2009 19:25:15 Alan Cox wrote:
Quoted 5 lines
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 UDMAA 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
Quoted 7 lines
You mean the content ?
Quoted 2 lines
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
You want facts? Here we go:
https://bugzilla.redhat.com/show_bug.cgi?id=250349
https://bugzilla.novell.com/show_bug.cgi?id=457037
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/399616
Quoted 6 lines
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.
I regret this work -- because of it I share the blame for the new driver and keep getting complains about it..
Quoted 3 lines
Quoted 1 line
for their (this includes me of course) hard work.
All because you wouldn't work on the libata ones which had a future. You
The rest of your mail is "the same good old straw-man" to put me back into specially created for me by you & co. "difficult to work with" box.
Guys, "the devil" has been long out of the box.. :)
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 4 lines
Quoted 2 lines
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
You want facts? Here we go:
So you spent the day searching bugzillas.. congratulations. Btw you missed one. I have a total of four reports I know about.
Quoted 2 lines
I regret this work -- because of it I share the blame for the new driver and keep getting complains about it..
Amazing.. I don't.
I look forward to receiving patches from Red Hat, SuSE or Ubuntu.
Alan
Quoted 6 lines · On Saturday 14 November 2009 17:04:38 Alan Cox wrote:
Quoted 4 lines
Quoted 2 lines
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
You want facts? Here we go:
So you spent the day searching bugzillas.. congratulations. Btw you
Lol, how come's that you know better then me what I do? :)
[ I didn't spend a single minute on it, some good people pinged me for help
and gave me bugzilla numbers.. ]
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 15 lines · On Saturday 14 November 2009 00:46:29 Bartlomiej Zolnierkiewicz wrote:
Quoted 8 lines · On Friday 13 November 2009 19:25:15 Alan Cox wrote:
Quoted 5 lines
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 UDMAA 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 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 for their (this includes me of course) hard work.
Quoted 6 lines
Especially given your complete lack of familiarity with post-2004 changes.
See for yourself, *50* mostly _trivial_ patches during *5* years:
[ "git log --follow --since="5 years ago" drivers/ide|grep "Author: Alan Cox" -B1 -A3"
output edited for easier reading ]
I've also looked at ATA side of the things for the last *3* years now:
$ git log --follow --since="3 years ago" drivers/ata|grep "Author: Alan Cox"|wc -l 173
[ ~5 patches a month and most of the work was to bring PATA on the level that
old IDE code has offered back in 2005.. ]
also before people start calling me names or teach me about "accumulated credibility" concept:
I'm in no way trying to deny people's past achievements (hey, I got inspired by Alan's work myself in early days) but I would like to raise the awareness that these days it is a way more difficult than it was in the past to make significant and/or large scale changes so new people are stuck in Catch22 when it comes to "accumulated credibility"..
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Skipping the technical merit of the quoted text for the moment -- I find 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 for their (this includes me of course) hard work.
Without making any judgement about the relative quality of the drivers in their role as IDE drivers, the fact that ACPI hotplug works with libata and doesn't work with drivers/ide means that, rationally, distributions need to use the libata stack for the more common parts. There simply isn't the same level of integration between drivers/ide and the rest of the OS.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 11 lines · On Saturday 14 November 2009 03:29:51 Matthew Garrett wrote:
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Skipping the technical merit of the quoted text for the moment -- I find 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 for their (this includes me of course) hard work.
Without making any judgement about the relative quality of the drivers in their role as IDE drivers, the fact that ACPI hotplug works with libata and doesn't work with
drivers/idemeans that, rationally, distributions need to use the libata stack for the more common parts.
This doesn't change the fact that there are real regressions present in libata host drivers and people who should be responsible for fixing them are just ignoring them..
Quoted 2 lines
There simply isn't the same level of integration between
drivers/ideand the rest of the OS.
Fully agreed but it doesn't change anything for issues discussed.
On the side note -- certain distributions, I'm sure you know which one I mean specifically [1], "helped" a lot in making sure that such level of integration would be very difficult to achieve (ACPI hotplug was added later than some distributions, again you know which one I mean specifically [1], switched to libata _only_ for PATA).
[1] The one whose developers love to blame every damn single problem on everybody else from PC hardware designers ;) through BIOS' writers to ordinary users.. instead (if only from time to time) considering that there could be something wrong with their own development process if they constantly miss fixes done by their competitors..
Signature · 1 line
Bartlomiej Zolnierkiewicz
Quoted 20 lines · On Saturday 14 November 2009 03:54:01 Bartlomiej Zolnierkiewicz wrote:
Quoted 11 lines · On Saturday 14 November 2009 03:29:51 Matthew Garrett wrote:
Quoted 4 lines · Bartlomiej Zolnierkiewicz
Skipping the technical merit of the quoted text for the moment -- I find 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 for their (this includes me of course) hard work.
Without making any judgement about the relative quality of the drivers in their role as IDE drivers, the fact that ACPI hotplug works with libata and doesn't work with
drivers/idemeans that, rationally, distributions need to use the libata stack for the more common parts.This doesn't change the fact that there are real regressions present in libata host drivers and people who should be responsible for fixing them are just ignoring them..
Quoted 2 lines
There simply isn't the same level of integration between
drivers/ideand the rest of the OS.
Quoted 7 lines
Fully agreed but it doesn't change anything for issues discussed.
On the side note -- certain distributions, I'm sure you know which one I mean specifically [1], "helped" a lot in making sure that such level of integration would be very difficult to achieve (ACPI hotplug was added later than some distributions, again you know which one I mean specifically [1], switched to libata _only_ for PATA).
I've checked this now:
23 January 2007 F7 Test1 development freeze
..
31 May 2007 F7 General Availability
vs.
ommit 237d8440cb2b104a3b97fc971a9bce67960bb616
Author: Matthew Garrett <[email protected]> AuthorDate: Wed Oct 3 01:24:16 2007 +0100 Commit: Jeff Garzik <[email protected]> CommitDate: Fri Oct 12 14:55:45 2007 -0400
libata: Integrate ACPI-based PATA/SATA hotplug - version 5
Modern laptops with hotswap bays still tend to utilise a PATA interface on a SATA bridge, generally with the host controller in some legacy emulation mode rather than AHCI. This means that the existing hotplug code in libata is unable to work. The ACPI specification states that
...
Please take a look at dates and author of the commit.
You helped create such situation in the first place and now you try to use it as an technical argument to justify past decisions.
Anyway it doesn't matter here at all.
Why are people even bringing this or quality of "old" IDE host drivers in the discussion as a justification for the quality of _new_ drivers?
Double standards and hypocrisy comes to a mind.
Signature · 1 line
Bartlomiej Zolnierkiewicz
Jeff Garzik
AppliedQuoted 12 lines · Robert Hancock
Remove the experimental tag on Parallel ATA drivers. Though some of the individual PATA drivers are still marked as experimental, as a group they can hardly be considered to be, given they've been used in various distros for some time.
Signed-off-by Robert Hancock<[email protected]>drivers/ata/Kconfig +0
-0
drivers/ata/Kconfig line 8
Quoted 7 lines
drivers/ata/Kconfig +1
-1@@ -3,7 +3,7 @@ # menuconfig ATA - tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers" + tristate "Serial ATA and Parallel ATA drivers" depends on HAS_IOMEM depends on BLOCK
applied