On Thu, Oct 17, 2024 at 10:17:54AM -0700, John Hubbard wrote:
On 10/17/24 5:06 AM, Lorenzo Stoakes wrote:
+cc John, sorry I forgot to cc you on other replies!!
On Thu, Oct 17, 2024 at 09:08:19AM +0100, Lorenzo Stoakes wrote: [snip]
In any case I think copying the header to the tools/ directory with this linux/fcntl.h in some way stubbed out (we could even stub out fcntl.h there?) is the sensible way forward.
A 'just include the header' is simply not an option as it breaks the tests.
I should have read this one first, this morning, but I missed it initially. :)
No worries easily done! :)
Ohhh ok I think maybe we could have a good compromise that should (hopefully!) satisfy both you and John.
I can introduce tools/include/linux/pidfd.h that is a stub wrapper around the pidfd.h file.
So it can be something like:
#ifndef __TOOLS_LINUX_PIDFD_H #define __TOOLS_LINUX_PIDFD_H
/* * Some systems have issues with the linux/fcntl.h import in linux/pidfd.h, so * work around this by setting the header guard. */ #define _LINUX_FCNTL_H #include "../../../include/uapi/linux/pidfd.h" #undef _LINUX_FCNTL_H
#endif /* __TOOLS_LINUX_PIDFD_H */
Then the test code needs only to update the pidfd.h file to #include <linux/pidfd.h> and add a simple $(TOOLS_INCLUDES) to the CFLAGS += line in the pidfd self tests Makefile and we should be all good.
Yes.
That way we always import everything in this header correctly, we directly document this issue, we include the header as you would in userland and we should cover off all the issues?
Very nice!
Thanks!
I saw from your other thread the idea was to take snapshots and to run scripts to compare etc. but I suppose putting this into the known-stub directory tools/include/linux rather than tools/include/uapi/linux would avoid a conflict here.
Or would you say the wrapper should regardless be in the uapi/linux directory?
Thanks!
thanks,
John Hubbard