Hey, On Sat, Aug 10, 2013 at 02:17:24AM +0400, Sergei Shtylyov wrote: > 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? Because it's just more churn? Now TF basically matches what goes into FIS. Adding aux to qc break that for no good reason (no, 4 bytes isn't a good reason). > 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. Oh sure, we'll carry the existing ones and there will be new drivers for sure. I'm saying that in terms of command protocol and standard, it is and has long been a dead end. Nothing can happen there anymore. There's no point in putting TF based interface in the center of attention. > >I don't see why you're getting all passive agressive about it. > > Don't intimidate me with psychological terms. :-) Please adjust your tone then because your original reply was very easily escalatable. If you want to escalate things, I'm game but if you don't want that, please make that clear too. > >If you have technical arguments, dish them out. > > I have. It seems you intentionally ignore them, and reply to > non-technical passage only. The only concrete thing I got upto this point is saving 4 bytes, which is a bit difficult to consider seriously. Other parts, I don't get at all. Sure there are TF drivers, but how does adding aux field to TF make it worse for them? 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
