Hi Andy,

On 3/6/20 4:04 PM, Andy Lutomirski wrote:

[...]

quoted

To solve the problem, I decided to use the approach below:
 * Extract from include/linux/ the vDSO required kernel interface
   and place it in include/common/

I really like the approach, but I’m wondering if “common” is the right name. This directory is headers that aren’t stable ABI like uapi but are shared between the kernel and the vDSO. Regular user code should *not* include these, right?

Would “vdso” or perhaps “private-abi” be clearer?

Thanks! These headers are definitely not "uapi" like and they are meant to
evolve in future like any other kernel header. We have just to make sure that
the evolution does not break what we are trying to achieve with this series.

I have to admit that I spent quite some time in choosing the name and I am not
completely satisfied with "common" either. The reason why I ended up with this
is that the headers are common in between the kernel and the vdso (userspace)
but I agree that it does not make completely self explanatory.

Using "vdso" would mean according to me that those are vdso only headers,
probably "private-abi" is the best choice here. If there is enough consensus, I
am happy to rework my patches accordingly. What do you think?

quoted

 * Make sure that where meaningful the kernel includes "common"
 * Limit the vDSO library to include headers coming only from UAPI
   and "common" (with 2 exceptions compiler.h for barriers and
   param.h for HZ).
 * Adapt all the architectures that support the unified vDSO library
   to use "common" headers.

[...]

-- 
Regards,
Vincenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel