linux-kernel - Merging libata PATA support into the base kernel

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-next>] [day] [month] [year] [list]

Date:	Wed, 09 Aug 2006 18:29:59 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Merging libata PATA support into the base kernel

Jeff (rightly) thinks the plan should be discussed publically, so here
is the plan

For 2.6.19 to move the libata drivers to drivers/ata
Add a subset of the new PATA drivers living in -mm to the base kernel

Many of the new libata drivers are already more stable and functional
than the drivers/ide ones. 


What does this mean for end users selecting the existing IDE layer
- Zilch, Nada, Nothing
- No changes in behaviour, no different code paths

For the more adventurous
- Better SATA/PATA integration
- Support for some chipsets not supported by drivers/ide
	(jmicron, newer VIA, mpiix, netcell, efar, etc)
- Active maintainance and updates
- Better quality drivers and error handling
- Inevitably more interesting bugs to find and help fix
- A chance to knock out any bugs and assumptions with other platforms

The new libata PATA support has some caveats at the moment
- No support for certain old serialized devices
- No support for prehistoric CMD640 controllers
- No support for host-protected-area yet
- Drives appear as /dev/sda /dev/sr0 etc along with the libata SATA
devices (and since you can't tell SATA from PATA at times its hard to
avoid). That means people with some older distros wanting to try it
might need to change their fstab or rootdev. People not trying it won't
be affected.

At this point in time it is premature to discuss or plan the point at
which the old IDE layer would go away. That discussion can start at the
point where everyone is happy that the new libata based layer is
providing better quality and coverage than the old one. Even then there
would be no need to hurry.

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/