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

From: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>
Date: Mon, 12 Oct 2026 17:55:25 UTC
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

Regards.

> 
> Kind regards,
> 
> oh
> 
> -- 
> 
> A FreeBSD user


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>