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

On Mon, 12 Oct 2026 18:13:40 +0000 (UTC)
"Bjoern A. Zeeb" <bz@FreeBSD.org> wrote:

> 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.

I think pulling in something from /usr/obj/ for ports kmods
itself is a bad idea, as it's NOT guaranteed to be existing
on invoking `make` in ports directory when stable/16 and
releng/16.0 are branched in the future for anyone NOT building
base locally.


> 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.

Putting attached file (made the change to fit for files/ without
touching ports Makefile) into files/ directory of each
graphics/drm-*-kmod may be easier to test.

Confirmed causing no harm on build for graphics/drm-612-kmod
and graphics/nvidia-drm-612-kmod-devel on stable/15 (there's no
opt_linuxkpi.h under /usr/obj/). But unfortunately I don't
have time to switch to main for now.

Maybe graphics/nvidia-drm-kmod/Makefile.common would need
to have additional hack to pick the patch, as files/ in
each graphics/nvidia-drm-*-kmod* are to be applied to
NVIDIA parts only (DRM parts are extracted along"side").


> 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]


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