From: Jeff Garzik <jgarzik@pobox.com>
To: Mark Lord <lkml@rtr.ca>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
Linux Kernel <linux-kernel@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: new tool: blktool
Date: Thu, 19 Aug 2004 13:57:10 -0400 [thread overview]
Message-ID: <4124E9F6.6030000@pobox.com> (raw)
In-Reply-To: <4124E701.5020905@rtr.ca>
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)
next prev parent reply other threads:[~2004-08-19 17:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-15 21:36 new tool: blktool Jeff Garzik
2004-08-15 20:55 ` Alan Cox
2004-08-15 22:07 ` Jeff Garzik
2004-08-15 22:18 ` David Ford
2004-08-15 22:22 ` Anton Starikov
2004-08-15 22:40 ` Jeff Garzik
2004-08-15 23:00 ` Anton Starikov
2004-08-15 23:27 ` Mark Lord
2004-08-15 23:34 ` Mark Lord
2004-08-15 23:44 ` Jeff Garzik
2004-08-15 23:36 ` Jeff Garzik
2004-08-16 2:36 ` Mark Lord
2004-08-16 16:53 ` Jeff Garzik
2004-08-19 15:03 ` Mark Lord
2004-08-19 15:51 ` Bartlomiej Zolnierkiewicz
2004-08-19 17:44 ` Mark Lord
2004-08-19 17:50 ` Jeff Garzik
2004-08-19 17:57 ` Jeff Garzik [this message]
2004-08-19 18:01 ` Mark Lord
2004-08-19 18:04 ` Mark Lord
2004-08-19 18:12 ` Jeff Garzik
2004-08-19 18:42 ` Mark Lord
[not found] <2tATw-7md-25@gated-at.bofh.it>
[not found] ` <2tCLz-dp-3@gated-at.bofh.it>
2004-08-15 23:54 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4124E9F6.6030000@pobox.com \
--to=jgarzik@pobox.com \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@rtr.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.