On 10/17/24 11:38, Lorenzo Stoakes wrote:
On Thu, Oct 17, 2024 at 10:37:00AM -0700, John Hubbard wrote:
On 10/17/24 10:28 AM, Lorenzo Stoakes wrote:
On Thu, Oct 17, 2024 at 10:17:54AM -0700, John Hubbard wrote:
On 10/17/24 5:06 AM, Lorenzo Stoakes wrote:
...
#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.
I like this solution. I should have read this message first before
handling the others.
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
Actually, I'm not running scripts, because the only time things need to
change is when new selftests require a new include, or when something
changes that selftests depend on.
tools/include/linux rather than tools/include/uapi/linux would avoid a conflict
here.
This is the first time I've actually looked at tools/include/linux. That
sounds about right, though.
Or would you say the wrapper should regardless be in the uapi/linux directory?
No, not if there is already a better location, as you pointed out.
OK perfect, I have a patch series ready to go with this (and addressing
Christian's comments).
Shuah - if you are open to this approach then we should be good to go!
I am caught up with the discussion now. I am good with this change.
Reviewed-by: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>
thanks,
-- Shuah
