Re: [PATCH net-next 0/2] refactor the ringtest testing for ptr_ring

On Mon, Jul 05, 2021 at 10:05:30PM +0300, Andy Shevchenko wrote:

On Mon, Jul 5, 2021 at 9:45 PM Michael S. Tsirkin [off-list ref] wrote:

quoted

On Mon, Jul 05, 2021 at 09:36:26PM +0300, Andy Shevchenko wrote:

quoted

On Mon, Jul 05, 2021 at 02:26:32PM -0400, Michael S. Tsirkin wrote:

quoted

On Mon, Jul 05, 2021 at 08:06:50PM +0800, Yunsheng Lin wrote:

quoted

On 2021/7/5 17:56, Andy Shevchenko wrote:

quoted

On Mon, Jul 05, 2021 at 11:57:33AM +0800, Yunsheng Lin wrote:

quoted

tools/include/* have a lot of abstract layer for building
kernel code from userspace, so reuse or add the abstract
layer in tools/include/ to build the ptr_ring for ringtest
testing.

...

quoted

 create mode 100644 tools/include/asm/cache.h
 create mode 100644 tools/include/asm/processor.h
 create mode 100644 tools/include/generated/autoconf.h
 create mode 100644 tools/include/linux/align.h
 create mode 100644 tools/include/linux/cache.h
 create mode 100644 tools/include/linux/slab.h

Maybe somebody can change this to be able to include in-tree headers directly?

If the above works, maybe the files in tools/include/* is not
necessary any more, just use the in-tree headers to compile
the user space app?

Or I missed something here?

why would it work? kernel headers outside of uapi are not
intended to be consumed by userspace.

The problem here, that we are almost getting two copies of the headers, and
tools are not in a good maintenance, so it's often desynchronized from the
actual Linux headers. This will become more and more diverse if we keep same
way of operation. So, I would rather NAK any new copies of the headers from
include/ to tools/include.

We already have the copies
yes they are not maintained well ... what's the plan then?
NAK won't help us improve the situation.

I understand and the proposal is to leave only the files which are not
the same (can we do kinda wrappers or so in tools/include rather than
copying everything?).

I have no idea how we'd do all this. When I did tools/virtio I already
tried to minimize copying. Want to try to do better?

quoted

I would say copies are kind of okay just make sure they are
built with kconfig. Then any breakage will be
detected.

quoted

quoted

quoted

quoted

Besides above, had you tested this with `make O=...`?

You are right, the generated/autoconf.h is in another directory
with `make O=...`.

Any nice idea to fix the above problem?

-- 
With Best Regards,
Andy Shevchenko