On Tue, 13 Oct 2026, Tomoaki AOKI wrote:

On Mon, 12 Oct 2026 17:21:39 +0200
A FreeBSD User <[email protected]> wrote:

Am Tage des Herren Sun, 11 Oct 2026 22:07:36 +0100
Nuno Teixeira <[email protected]> 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]

Reply via email to