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.
