Mark Lord wrote:

Simply dropping HDIO_DRIVE_CMD/HDIO_DRIVE_TASK into there would
immediately gain full compatibility with the existing toolsets,
and give some time for a newer scheme to be rolled out in the
kernel, the tools, and ultimately all of the various distros.

Addendum:  don't misunderstand my other emails, I do agree with what 
you're saying above.  But random thoughts (some of which conflict with 
each other):

* In Linux we want to keep ancient userland binaries working for as long 
as possible.

* I don't mind HDIO_DRIVE_TASK nearly as much as HDIO_DRIVE_CMD, since 
the command protocol is available.  But if I give in and decide that a 
command opcode->protocol lookup table is inevitable for supporting 
legacy interface, then I might as well implement both HDIO_DRIVE_TASK 
and HDIO_DRIVE_CMD.

* OTOH, this is an excellent opportunity to _not_ implement these 
ioctls, if an obviously-better interface is available.  Since libata and 
SATA are new drivers using new interfaces, it's not difficult to move 
things to new interfaces.

* And it's not a big deal to update blktool and hdparm to use <new 
method X> to send ATA taskfiles, rather than existing HDIO_DRIVE_xxx. 
(that leaves only existing applications)