From: Tejun Heo <htejun@gmail.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: 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 18:19:23 +0900 [thread overview]
Message-ID: <43F5951B.3020605@gmail.com> (raw)
In-Reply-To: <43F58B7E.4000401@pobox.com>
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.
Hello, Jeff.
> 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.
Yeah, and another difficult question is - Are we going to exactly
replicate the behavior of IDE TASKFILE or try to fix / clean up? I have
no idea what should be done. The thing with TASKFILE is that it doesn't
have too many users but has enough annoying inconsistencies/bugs. So,
neither of rigorous replication or behavior cleanup feels right.
> 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.
I agree. HDIO_DRIVE_CMD and HDIO_DRIVE_TASK are orders simpler compared
to HDIO_DRIVE_TASKFILE and we don't even know what's TASKFILE's correct
behavior is. So, I think we should just leave TASKFILE out there in the
wilderness and watch it with sorrow as it dies slowly.
Also, as you pointed out, it's hardware-wise impossible to do
register-level granuality with SATA and I'll be surprised if any more
need for register-level granuality arises than there currently is. So,
I say we can forget about it without too much trouble. And if such need
EVER arises, let's hope SAT guys come up with something reasonable.
Thanks.
--
tejun
next prev parent reply other threads:[~2006-02-17 9:19 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 [this message]
2006-02-17 14:50 ` Mark Lord
2006-02-17 17:17 ` Erik Mouw
2006-02-17 18:27 ` Timothy Thelin
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=43F5951B.3020605@gmail.com \
--to=htejun@gmail.com \
--cc=erik@harddisk-recovery.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.