[lkml]   [2004]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

* 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.032 / U:1.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site