
Hi,
the grml team wants to collect feedback regarding the recent switch from PATA to LIBATA. PATA? LIBATA?
* PATA provides the old IDE subsystem (/dev/hdX), considered as legacy code. * LIBATA is the new subsystem (/dev/sdX) with new features, but some old IDE systems might not work with it.
Please participate in the poll! => http://doodle.com/vr75tpe4a2p6mwvt
We highly appreciate and need your feedback. Thanks!
regards, -mika-

Michael Prokop mika@grml.org: [...]
- PATA provides the old IDE subsystem (/dev/hdX), considered as legacy code.
- LIBATA is the new subsystem (/dev/sdX) with new features, but some old IDE systems might not work with it.
Okay, the advantage in using PATA is backwards compatibility, which is a good thing[tm].
The advantage of libata are the "new features".
For an educated decision, it would be good to know some drawbacks involved when reverting from libata. In other words: what does the user lose if grml reverts to pata?
Regards, Frank

* Frank Terbeck ft@grml.org [20090402 13:37]:
Michael Prokop mika@grml.org: [...]
- PATA provides the old IDE subsystem (/dev/hdX), considered as legacy code.
- LIBATA is the new subsystem (/dev/sdX) with new features, but some old IDE systems might not work with it.
Okay, the advantage in using PATA is backwards compatibility, which is a good thing[tm].
The advantage of libata are the "new features".
For an educated decision, it would be good to know some drawbacks involved when reverting from libata. In other words: what does the user lose if grml reverts to pata?
You're absolutely right, Frank - thanks. But I didn't want to provide too many details before I've feedback from our user base.
regards, -mika-

* Michael Prokop mika@grml.org [20090402 11:28]:
the grml team wants to collect feedback regarding the recent switch from PATA to LIBATA. PATA? LIBATA?
- PATA provides the old IDE subsystem (/dev/hdX), considered as legacy code.
- LIBATA is the new subsystem (/dev/sdX) with new features, but some old IDE systems might not work with it.
Please participate in the poll! => http://doodle.com/vr75tpe4a2p6mwvt
Oh my dear... I meant *IDE* (as in CONFIG_IDE) vs. LIBATA/PATA of course. No idea what was riding me... (thanks to maks for the hint) - sorry for that! :-/
In case you got a mail and are confused what just happend: the question mark in the first column of the poll just visualises that the option was adjusted by the poll admin (that's me). I just replaced the word "PATA" with "CONFIG_IDE" (no further changes - promissed :)) - and this caused to mark this option with the '?' on every single vote (sorry, I wasn't aware of that when editing, yeah not my best day ;-)).
But as all of you got the idea anyway and I've the answer I was looking for I just closed the poll. The overall result:
40 participants
38 votes for 'Stay with LIBATA' and just two persons without answering this option overall. So not a *single* vote for falling back to the old subsystem code. This is great! :)
JFTR: I made a screenshot of the vote which visualises the result of the poll before I edited it (regarding PATA/CONFIG_IDE):
http://grml.org/screeni/gkrellShoot_09-04-06_154033.png
We've 35 votes for 'grml 2008.11 boots fine on my system(s)', 5 votes without answering this question.
Just 3 votes for 'grml 2008.11 does not boot on my system(s)'. I'd love to get hardware information from those people so I can contact the LIBATA maintainers with according information!
Now, what's the benefit from using LIBATA? Mainly (improved) support for Native Command Queueing (NCQ) and hotplugging - check out:
http://linux-ata.org/ http://ata.wiki.kernel.org/index.php/Main_Page
As Ubuntu, RedHat/Fedora/... chose to go with LIBATA-only and get rid of old CONFIG_IDE as well I think it's the way to go in the long run. And if you encounter any problems: *please* let us know!
Thanks to all of you who voted!
regards, -mika-
Teilnehmer (2)
-
Frank Terbeck
-
Michael Prokop