Hi Lorenzo Stoakes,
On Fri, Jul 11, 2025 at 09:34:38AM +0100, Mark Brown wrote:
On Thu, Jul 10, 2025 at 12:28:13PM -0400, Zi Yan wrote:
On 10 Jul 2025, at 4:42, Mark Brown wrote:
On Wed, Jul 09, 2025 at 10:46:07AM -0400, Zi Yan wrote:
Right. My /usr/include/sys does not have pidfd.h. IMHO selftests should not rely on userspace headers, otherwise we cannot test latest kernel changes.
That's not realistic, we need to be able to use things like libc and for many areas you'd just end up copying or reimplmenenting the userspace libraries. There's some concerns for sure, for example we used to have
Sure. For libraries like libc, it is unrealistic to not rely on it. But for header files, are we expecting to install any kernel headers to the running system to get selftests compiled? If we are testing RC versions and header files might change before the actual release, that would pollute the system header files, right?
Right, for the kernel's headers there's two things - we use a combination of tools/include and 'make headers_install' which populates usr/include in the kernel tree (apparently mm rejects the latter but it is widely used in the selftests, especially for architecture specifics). These install locally and used before the system headers.
OTOH in a case like this where we can just refer directly to a kernel header for some constants or structs then it does make sense to use the kernel headers, or in other cases where we're testing things that are
That is exactly my point above.
What was said was a bit stronger though, and might lead people down a wheel reinvention path.
Let's PLEASE not rehash all this again...
This patch literally just needs PIDFD_SELF, I've provided a couple of ways of doing that without introducing this requirement.
We already have a test that uses this with no problems ever reported on which this patch was based.
Thanks.
You are absolutely right, and my apologies for introducing this unnecessary header dependency.
Just to clarify, the build failure Zi Yan reported on arm64 was not caused by PIDFD_SELF. It was from my use of the pidfd_open() glibc wrapper in the test, which incorrectly pulled in the system's <sys/pidfd.h>.
Based on our discussion and a review of other tests, I understand the correct approach is to avoid such dependencies. I will fix this properly in the next version by using a direct syscall wrapper for pidfd_open. Thank you for the guidance.
Best regards, Wang Lian