Patch updated to fix remaining comments.

In D21172#460271, @jbeich wrote:

@jmd or @zeising, can you update devel/libclc to a more recent LLVM snapshot? lang/clover (P294) compiles fine against LLVM 9 API while linking errors maybe unrelated.

I trust that it runs fine in poudriere and so on. :)

In D20992#460070, @jhb wrote:

So with this change people will rebuild the module on current without having to reinstall the port, so I think this will effectively do the recommended change, but even more strongly on current. I think that any pre-built kernel modules are always going to have to be targeted at a kind of lowest-common-denominator. We aim to do this already for standalone kernel module builds (so cd /sys/modules/foo; make is the same problem space).
If you really want to customize kernel modules to the running kernel then I think the next step you might consider is to build modules during the post-install step of the package being installed. However, for people running releases, I think shipping a pre-built module that will work with GENERIC is sufficient. In that sense I'm pretty happy with where the current LOCAL_MODULES scheme ends up.

Minor nits, I noticed them, but feel free to change or leave them as-is.

lgtm (I only glanced at the patch, and haven't tested it, though).

In D20992#458955, @jhb wrote:

In D20992#458720, @zeising wrote:

In D20992#455803, @jhb wrote:

@zeising: With the related changes (see the stack, and you've commented on the drm-current-kmod one), a normal GENERIC kernel on head defines INVARIANTS and trips over this. If you apply the other two changes and install the updated package and try to build GENERIC you will hit this.

I'm not sure I understand this comment.
The kmod is built using the kmod facility in ports, and bsd.kmod.mk. I don't know if INVARIANTS and other options gets set by that, but it seems they don't. If the build when building out of tree (building the port) vs. building in tree is different because of this (and other options), this would mean we get different drivers depending on how they are built, and this feels like it's going to become a support nightmare. Perhaps options such as these should be stripped before building ports modules together with source, to avoid this issue.

It's more like getting reliably working modules on HEAD instead of random crashes and panics due to a mismatch in the kernel and module environment. Standalone modules only work with non-changing kernels (e.g. a user staying on a release) or with modules that use stable, well-supported interfaces like (the graphics drivers do not as they regularly use VM internals). Plus, running the graphics drivers with debugging enabled on HEAD such as INVARIANTS is more likely to find bugs more quickly and more nicely. virtualbox is in a similar situation where it needs to be paired with the running kernel instead of mixing old and new versions of kernel interfaces.

In D20990#458950, @jhb wrote:

In D20990#458719, @zeising wrote:

In D20990#456269, @johalun wrote:

Having to specify each source and header file seems like a huge maintenance burden. For every update in Linux version files get added, removed and renamed. Some sort of recursive directory install would be nice...

This is just how ports work, the package list (pkg-plist) must contain all files that are to be installed, otherwise pkg doesn't know how to create a package from the files in the staging area.

There are some ways to do automatic plist general, but my understanding is that portmgr@ generally frowns on it as they want to preserve the ability to grep for a file in all the pkg-plist files. *shrug* FWIW, I generated the list of files with 'find' fairly easily. 'make check-plist' is also handy to let you know if you have it wrong.

In D20992#455803, @jhb wrote:

@zeising: With the related changes (see the stack, and you've commented on the drm-current-kmod one), a normal GENERIC kernel on head defines INVARIANTS and trips over this. If you apply the other two changes and install the updated package and try to build GENERIC you will hit this.

In D20990#456269, @johalun wrote:

Having to specify each source and header file seems like a huge maintenance burden. For every update in Linux version files get added, removed and renamed. Some sort of recursive directory install would be nice...

Thank you for working on this!

I don't think the drm kmods are built with INVARIANTS, unless it's somehow passed into the build environment when building out of tree kmods. In general, are there other options added when building the DRM kmods (or other kmods) as part of the kernel build?

In D20724#455153, @antoine wrote:

This breaks ports that test something and set USE_XORG between bsd.port.pre.mk and bsd.port.post.mk.
Also, I have the feeling that there is a .include "${USESDIR}/*.mk" abuse in xorg-cat.mk, in my opinion this should be pushed to the USES line in individual ports.

Updates based on comments from @mat

Update patch, add documentation for USES=xorg-cat as well.

Submitted for exp-run in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238988 .

Update based on latest comments. Ready for exp-run now.