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:

quoted

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