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