Re: drm-66-kmod build fail during main-n290014-7a48c3fd3e6e -> main-n290042-9f0432041b8f

On Tue, 13 Oct 2026, Tomoaki AOKI wrote:

> On Mon, 12 Oct 2026 17:21:39 +0200
> A FreeBSD User <freebsd@walstatt-de.de> wrote:
>
>> Am Tage des Herren Sun, 11 Oct 2026 22:07:36 +0100
>> Nuno Teixeira <eduardo@freebsd.org> schrieb:
>>
>>> Hello,
>>>
>>> 37:
>>>> /usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h:33:10: fatal
>>>> error: 'opt_linuxkpi.h' file not found
>>>>    33 | #include "opt_linuxkpi.h"
>>>>       |          ^~~~~~~~~~~~~~~~
>>>
>>>
>>> I've reported today at
>>> https://lists.freebsd.org/archives/dev-commits-src-all/2026-October/082012.html
>>>
>>> Cheers,
>>>
>>
>> Ups. I did also for port graphics/drm-612-kmod a few minutes ago. The header file in question
>> is simply not in the most recent source tree ... very strange ;-)
>
> Good point.
>
> It SHOULDN'T be under /usr/src/, but under /usr/obj/, as it's generated
> on "kernel build time".
>
> This means, it shouldn't exist unless you built kernel
> yourself locally.
>
> Thus, I believe it SHOULDN'T be required for out-of-tree
> kmods (in ports or in the wild).
>
> If it's REALLY mandatory for out-of-tree kmod builds
> and fix in out-of-tree kmod side, error message to request
> local kernel builds first should be needed.
>
> If not, guards for #include NOT to be included except for
> kernel builds in src side would be the best fix.
>
> IIRC, it's the way usually done for this kind of situations,
> but I'm not enough sure if opt_linuxkpi.h is really mandatory
> or not for out-of-tree kmod builds.
>
> Note that, as far as I could confirm, there are 3 headers
> attempting to include opt_linuxkpi.h in offending commits
> (at least). And LINUXKPI_DEBUG could be appropreate to be
> used for safeguard?
>
> /usr/src/sys/compat/linuxkpi/common/include/linux/spinlock.h
> /usr/src/sys/compat/linuxkpi/common/include/linux/kconfig.h
> /usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h

The sole problem here is that drm-kmod is handrolling stuff
instead of using the kmod,mk provided defines.

Apply the changes from the pull request and what's in drm-kmod
master already and it'll build along with a kernel, as a standalone
git checkout or from ports.  If there's a 4th method, please let me
know.

As a plus (once cleanup gets done beyond initial repair), in the
future this kind of breakage shouldn't happen anymore and there's
going to be a single place to track SRCS+= and CFLAGS+= dependencies
needed to use LinuxKPI.

So yes, please see https://github.com/freebsd/drm-kmod/pull/524

-- 
For there shall arise false Christs, and false prophets, and shall shew
great signs and wonders; insomuch that, if it were possible, they shall
deceive the very elect. Behold, I have told you before. [Mat. 24:24-25]