Re: [PATCH v3 1/3] libata: Populate host-to-device FIS "auxiliary" field

[Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>]

Hello.

On 08/10/2013 01:51 AM, Tejun Heo wrote:

>>     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).

> Can you explain why following the traditional TF definition matters so
> much?

    Because it's more clear, saves some memory and matches the (rather poor) 
capabilities of the libata's driver taskfile interface (which you can't throw 
out however you wanted).

> What practical difference does that make?  The new field is
> part of command code definition, so it belongs with the rest of them
> regardless of what the structure it's contained in is named.

    So why not place it to 'struct ata_queued_cmd' then? If it doesn't really 
matter where to put it if it serves to describe a command, and additionally 
will save you some memory?

> If the only reason for strictly separating TF regs into a separate struct is
> because the spec says so,

    No. Besides, as I told you, taskfile isn't in any spec, it's pre-ATA term.

> I indeed don't give a flying hoot.

    Excellent reply from a maintainer. :-D

> Also, the only controller interface which would continue to be
> relevant is ahci and that's it.  There will be no new development
> whatsoever happening with TF based interface, ever.

    In x86 world maybe but how much does it help you with the legacy stuff you 
have to drag around?
    Tell about AHCI to my embedded customer, Renesas. Remember the most recent 
sata_rcar driver I have submitted? It's taskfile based (there's also SATA 
driver we at MontaVista did write but didn't submit). And it's used in their 
top-notch R-Car SoCs.

> I don't see why you're getting all passive agressive about it.

    Don't intimidate me with psychological terms. :-)

> If you have technical arguments, dish them out.

    I have. It seems you intentionally ignore them, and reply to non-technical 
passage only.

> Thanks.

WBR, Sergei