From: Timothy Thelin <timothy.thelin@wdc.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Tejun Heo <htejun@gmail.com>,
Erik Mouw <erik@harddisk-recovery.com>, Mark Lord <liml@rtr.ca>,
linux-ide@vger.kernel.org
Subject: Re: TASKFILE ioctl for libata?
Date: Fri, 17 Feb 2006 10:27:12 -0800 [thread overview]
Message-ID: <1140200833.7509.101.camel@localhost> (raw)
In-Reply-To: <43F58B7E.4000401@pobox.com>
On Fri, 2006-02-17 at 03:38 -0500, Jeff Garzik wrote:
> Tejun Heo wrote:
> > Just a side note. Taskfile has finer granuality regarding which
> > registers are written and read back than current libata does and IDE
> > taskfile implementation is somewhat broken/weird in a few delicate fun
> > ways, so... be careful. Whoever tries it.
>
> Yes -- it opens the question about whether we care enough to fully
> support flagged taskfiles, and if not, how to best emulate that support
> under libata.
>
> I'm told that flagging individual ATA shadow registers for modification
> (or not) is required for issuing certain specialized PATA
> vendor-specific commands. SATA, OTOH, transmits all ATA shadow
> registers in a FIS, so flagged taskfiles are useless.
>
> So, I'm now thinking the best route is to leave the code as it is ;-)
> Rather than imperfectly implementing the flagged taskfile ioctl, punt
> the remaining userland users to SG_IO.
>
> I don't see lack of full flagged taskfile support as a big stumbling
> block to libata use.
>
> Jeff
FYI, Western Digital doesn't need flagged taskfile access to use its
vendor specific commands; SAT passthru works fine (although we'd
appreciate more of the protocols implemented, or at least a way to
discover at runtime which ones are implemented before trying to use
them).
- Tim Thelin
next prev parent reply other threads:[~2006-02-17 18:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-15 14:34 TASKFILE ioctl for libata? Erik Mouw
2006-02-15 19:00 ` Mark Lord
[not found] ` <a3d8b0a0602151257x52f6011bs1b37d9ac43b26619@mail.gmail.com>
2006-02-15 21:10 ` Matt Gillette
2006-02-16 0:06 ` Tejun Heo
2006-02-16 0:56 ` Erik Mouw
2006-02-16 2:20 ` Jeff Garzik
2006-02-16 9:30 ` Tejun Heo
2006-02-17 8:38 ` Jeff Garzik
2006-02-17 9:19 ` Tejun Heo
2006-02-17 14:50 ` Mark Lord
2006-02-17 17:17 ` Erik Mouw
2006-02-17 18:27 ` Timothy Thelin [this message]
2006-02-17 17:05 ` Erik Mouw
2006-02-17 17:15 ` Bartlomiej Zolnierkiewicz
2006-02-17 17:28 ` Erik Mouw
2006-02-17 18:13 ` Bartlomiej Zolnierkiewicz
2006-02-17 17:07 ` Erik Mouw
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=1140200833.7509.101.camel@localhost \
--to=timothy.thelin@wdc.com \
--cc=erik@harddisk-recovery.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
/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.