All of lore.kernel.org
 help / color / mirror / Atom feed
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)


  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.