Hello, Sergei. On Sat, Aug 10, 2013 at 01:39:08AM +0400, Sergei Shtylyov 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? 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. If the only reason for strictly separating TF regs into a separate struct is because the spec says so, I indeed don't give a flying hoot. 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. I don't see why you're getting all passive agressive about it. If you have technical arguments, dish them out. Thanks. -- tejun -- 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
