On Mon, Jun 19, 2017 at 06:43:48PM +0100, Russell King - ARM Linux wrote: > On Mon, Jun 19, 2017 at 06:18:18PM +0300, Yury Norov wrote: > > One else thing I forgot to ask - now you have the generic > > implementation for fncpy(), so do you really need to save arm > > version of it? > > This was covered in the review of v1, which took the ARM version > and incorrectly used it as an asm-generic implementation. > > I explicitly asked Florian _not_ to copy the ARM fncpy() version > to asm-generic because it has (surprise surprise) ARM specific > behaviours that do not belong in a cross-architecture generic > version. > > Namely, the ARM specific behaviour that bit 0 of a code address is > used to signal whether the code should be executed as ARM code or > as Thumb code. > > This behaviour has no meaning on other architectures (eg, x86) > where code addresses are not 32-bit aligned. > > So, suggesting that the ARM fncpy() should be used as an asm-generic > version is completely absurd, and just because we have an asm-generic > version also does not mean ARM should use it. > > Florian's approach to providing an asm-generic version, leaving the > ARM specific version is entirely correct and appropriate. > > So, in answer to your question, yes, we need _both_ an ARM specific > version and an asm-generic version, where the ARM specific version is > different from the asm-generic version. Purely because it needs > architecture specific details. Hi Russell, Florian, Thanks for clarifications. Thumb bit is a good reason to save arm version, and I completely agree with you in this. Sorry that missed it in the v1 discussion. > I explicitly asked Florian _not_ to copy the ARM fncpy() version > to asm-generic because it has (surprise surprise) ARM specific > behaviours that do not belong in a cross-architecture generic > version. But it seems that v3 does exactly that - copies arm with very small changes. :) Maybe there are good reasons to have arm version exactly how it looks now, but in general case, for me, some things that it does are not needed. I mean checking the alignment of the source and the type of destination. And after some headscratching I became even more convinced that for the general case it would be much preferable to write the fncpy() as regular function in .c file, not a macro, at least to have the corresponding symbol in binary and let the assembler code to call it, which is very probable. Yury -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
