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

  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.