Hello.
On 08/09/2013 06:53 PM, Tejun Heo wrote:
Ummm... I'm sorry but I'm gonna do 180 from Sergei on this one. The
That's very unfortunate for me. :-(
Hehe, sorry. :)
I've started to work on my taskfile patchset about a year ago (while being
in hospital) and worked on it on my copious free time (perhaps, not actively
enough until I realized I don't have much time anymore), so it doesn't sound
funny for me. If you're going to reject my patches once submitted outright,
just tell me now, and with some regret for the wasted time, I'll find a better
use for my free time, making a note to myself that the taskfile support in
libata is hopeless and the maintainer doesn't care a bit about that. (In case
you want an example of better taskfile support, look at IDE).
So, please put the aux field into ata_taskfile. That's where it
belongs.
Can't agree to that. I was going to make 'struct ata_taskfile'
reflect the historical notion and remove from it all not belonging
to that notion. Alas, libata has a bad history of mistreating the
historical terms...
But what does sticking to the historical definition give us when the
whole concept of TF is no longer maintained in new specs.
It predated even the old specs, so what?
The
distinction between "command proper" and "supporting / plumbing
information" is still useful
Yes, it's just the border was drawn incorrectly from the start IMO.
Jeff even placed the structure and friends into ata.h for no apparent reason
(part of those *enum* friends eventually got shared by IDE).
so I think it's natural to assign the
former to ata_taskfile and the latter to ata_queuedcmd.
That's exactly what I want to do.
After all, there are cases where we want to describe command without all the
plumbing stuff libata imposes
Exactly what I want to achieve.
and given that the aux field is part of
FIS proper it might even get used for command results too in the
future.
If and when this happens, we'll see. So far, the structure of H2D and D2H
FIS is different enough that libata doesn't have a stucture defined for FISes,
and just treats them as array of u8.
I mean, FIS is the new TF.
FISes are used by what, handful of controllers? While the others, even
SATA are still taskfile based and can't transfer FISes directly (especially
true for the embedded world where not everybody wants to use AHCI). So that's
kind of wishful thinking for now. And don't forget about the PATA legacy
you'll have to drag around forever.
We can rename ata_taskfile to
ata_fis and map things the other way but that'd just be extra churn.
Indeed. And totally stupid move concerning the amount of direct FIS
support in different hardware.
Thanks.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
