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
