Messages in this thread | | | Date | Thu, 19 Aug 2004 13:57:10 -0400 | From | Jeff Garzik <> | Subject | Re: new tool: blktool |
| |
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)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |