2.6.19 will be started after the 2.6.18 release
Libata PATA (Parallel ATA) merge By "Parallel ATA" we just mean all the ATA/IDE controllers and drives that we have been using for years before SATA. Almost from the start, one of the objectives of some kernel hackers was to [http://marc.theaimsgroup.com/?l=linux-kernel&m=115514409104283&w=2 replace the IDE drivers available in drivers/ide] (everything under the "Device drivers -> ATA/ATAPI/MFM/RLL support" configuration menu) by a re-implementation on top of libata, ie: the "SATA layer". Drivers/ide suffers from many ugly and obscure problems, and re-implementing it on top of libata has been much easier than fixing the unfixable drivers/ide mess. Alan Cox has been doing most of this porting work, and as consequence, the support for numerous IDE drivers has been reimplemented on top of SATA.
(Another consequence of this PATA merge is that libata and all its SATA drivers have also been moved from drivers/scsi (available in the "Device drivers -> SCSI device support -> SCSI low-level drivers" submenu) to drivers/ata (now "Device drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers"), and all the CONFIG_SCSI_FOOBAR options for the individual SATA drivers have been changed to CONFIG_FOOBAR, so this means you may need to reconfigure your SATA configuration options)
This means 2.6.19 may have two drivers for your PATA-base device: The old IDE driver under "Device drivers -> ATA/ATAPI/MFM/RLL support" and an alternative driver under "Device drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers" (along with the rest of the SATA drivers)
What one must you choose? Well, the safe option is using the old driver: The old drivers will continue working just as they did before. No changes for you if you choose those drivers, no behaviour changes at all.
What do the new libata-base PATA drivers offer to you?
- First of all, because they're libata-based and libata is a very well engineered and sane infrastructure, the drivers have much better quality, they're more clean, much better error handling (much better behaviour when one of your drives stops working or finds broken sectors), and they don't have some of the known design issues that the old drivers have (this is why people did all the work to move away from drivers/ide, they didn't do it just for fun)
- Because they're newer, there're inevitably bugs on them. For now, they're "experimental". If you want to be safe, use the old drivers.
- Really. Don't blame us if the new driver doesn't work for you, or harms your data (unlikely, but not impossible). If you want to be safe, use the old drivers.
- They support some chipsets not supported by drivers/ide (jmicron, newer VIA, mpiix, netcell, efar, etc). The cleaner design of libata allows easier driver development and maintenance.
- However, some IDE controllers are not supported or they aren't fully supported. Some of them because not all the IDE drivers have been ported to libata, but others because they're old and undocumented or because the libata PATA layer still doesn't support some of their features. There's no support for certain old serialized devices, for prehistoric CMD640 controllers or for host-protected-area yet.
- Drives appear as /dev/sda, /dev/sr0, the old devices names won't work. You may need to change your boot parameters and your /etc/fstab parameters in order to get a working system with the new drivers.
Eventually, the new libata-based PATA drivers will get stabler. The old drivers in drivers/ide may get deleted as the new drivers fulfill all needs of the IDE users and gets feature-complete, but this certainly won't happen anytime soon. And no old drivers will be deleted if there's not a working libata that can replace it. You can find the latest [http://zeniv.linux.org.uk/~alan/IDE/STATUS.txt status report] written by Alan Cox. It'd be certainly useful if you could give it a try and report back how it works for you to linux-kernel@vger.kernel.org or bugzilla.kernel.org - even if it works fine, it'll be useful to know what systems do work (be sure to include the necessary information mentioned in the previous status report) *