We do not expose LKPI API directly to userland. So no need in uapi/linux/eventfd.h

The goal is the same as D50851: it is to reproduce the same includes as Linux.

I frequently see a compilation failure because a source file relies on namespace pollution in Linux (it uses something but doesn’t include the associated header explicitly). As I don’t want to add a FreeBSD-specific include in DRM drivers, I search that mission inclued somewhere in linuxkpi.

This useless header for us is simply to avoid that work in the future.

Yes, I have a lot of #ifdef for #includes (and missing self-sufficiency of headers) in wireless drivers from the time before we had the dummy/includes and I would love to get rid of them as well. One man one for me is delay,h.

That said there is zero need to #include a dummy header inside linuxkpi/common. so I agree with @wulf here.

If you would grep drm-kmod for <uapi/ string, you would find references on only 3 files: uapi/linux/kfd_ioctl.h, uapi/drm/i915_drm.h and uapi/linux/sched/types.h. So they can't produce any significant namespace pollution.
Generally in LKPI uapi/ file contents should be just merged in to corresponding non-uapi file.

Even if linuxkpi doesn't need this extra header, Linux code might expect this to reproduce the same "graph".

It also makes it easier to compare sources from Linux and FreeBSD if we honor the same layout.

I prefer to have the exact same layout to make the porting effort less bumpy. This way, we know the provide the same API. We don't know how headers will be included in the future, so running a grep isn't helpful.

Of course, if you all prefer the opposite, I will change it. But I lost a fair amount of time solving these missing includes. I find it sad if we continue to introduce them.