Install kernel module sources and makefiles to
$PREFIX/sys/modules/drm-current-kmod. This permits kernel builds to build
the DRM modules as part of buildkernel via the LOCAL_MODULES framework.
These modules are installed to the kernel's directory and are then
preferred to the generic modules installed in /boot/modules.
Details
Details
- Reviewers
imp zeising manu - Group Reviewers
x11 - Commits
- rP508972: MFH: r508969 r508877 r508970 r508971
rP508877: Install kernel module sources for drm-current-kmod.
- Built a custom kernel and installed it to /boot/test after installing an updated package. The kernel in /boot/test includes DRM kernel modules built from these sources.
I did not bump PORTREVISION since this shouldn't affect the binaries,
but that can be added if it is deemed important.
Diff Detail
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 25714 Build 24297: arc lint + arc unit
Event Timeline
| graphics/drm-current-kmod/Makefile | ||
|---|---|---|
| 89 | It may be that Uses/kmod.mk should define this and the corresponding PLIST_SUB since I would expect other ports that install kernel module sources to follow the same convention? | |
| 100 | Using MAKEOBJDIRPREFIX avoided putting object files in the source directories preventing plist errors when the build directories are copied in the post-install target. | |
| graphics/drm-current-kmod/pkg-message | ||
| 8–9 | You don't need /boot/modules on HEAD where DRM2 isn't built and installed by default anymore, and once you build a kernel that installs its own DRM modules you need this variant instead for it to work properly. I think 12.0 also ships without DRM2, so we could perhaps makes this a pkg-message.in file that picks different versions based on the OS version (e.g. use this format for 12.0 and later and the /boot/modules one for older ones). | |
Comment Actions
Thank you for working on this!
You have added all the sources to the pkg-plist, but you don't always install all the sources, it's dependent on the architecture. This works on amd64, since all sources are used there, but not on other platforms.
Once we've got this somewhere we're happy, we should probably get buy-in from portmgr as well.
| graphics/drm-current-kmod/Makefile | ||
|---|---|---|
| 89 | Yes, it would be nice if this is handled by the kmod infrastructure. We can invent our own for now though, until more ports get on this though. | |
| 95 | At line 64 you set KMODSRC, but here you use something else, why? | |
| 100 | I believe this should eventually be handled by the infrastructure as well. | |
| 107 | You might need to check/set owner/permission of the files here as well. | |
| graphics/drm-current-kmod/pkg-message | ||
| 8–9 | This is probably a left over for when the drm2 kmods where in current as well. For 12.0, and indeed the entire 12 branch, the kmods are shipped as part of base. We tried to get rid of them before 12 branched, but there was too much push back on that, and we had to revert that change. For the stable branches, we also have to work around the fact that with this, we would build several kmods with the same name, that is probably not a good idea. drm-current-kmod is only used by CURRENT, we can get that working first. It's on current where the need to recompile the modules with each kernel is the biggest, and think about STABLE once we get this working. | |
Comment Actions
Hmm, I thought I matched what I do. I always install 'drivers' and 'include' which contains the bulk of the sources. The only conditional bits are the subdirectories that contain the module Makefiles, and those
are conditional (e.g. i915/Makefile)
Once we've got this somewhere we're happy, we should probably get buy-in from portmgr as well.
That's fine with me.
| graphics/drm-current-kmod/Makefile | ||
|---|---|---|
| 95 | For the PLIST_SUB it has to be a relative path that doesn't include STAGEDIR and PREFIX. | |
| 107 | Hmm, possibly. I'm not sure of the best way to handle that and will defer to what portsmgr / whoever thinks is the best approach. Using cp -r is convenient for having check-plist warn about missing / stable plist entries in the future as the port gets updated. | |
| graphics/drm-current-kmod/pkg-message | ||
| 8–9 | Ok. We can eventually use pkg-message.in if needed for the other ports in the future. I agree with focusing on just this port for now though. virtualbox-ose-kmod is another port that probably should be updated to use this once we are happy with the framework. | |
Comment Actions
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...
Comment Actions
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.
You have added all the sources to the pkg-plist, but you don't always install all the sources, it's dependent on the architecture. This works on amd64, since all sources are used there, but not on other platforms.
Hmm, I thought I matched what I do. I always install 'drivers' and 'include' which contains the bulk of the sources. The only conditional bits are the subdirectories that contain the module Makefiles, and those
are conditional (e.g. i915/Makefile)
You are right, I just didn't see it the first time, sorry for that. You probably have to give the same treatment to amdgpu and amdkfd as you give to i915 and vmgfx well though, since they aren't built on i386, and other architectures.
It feels a bit like we need to make a decision, either we install all the sources, including makefiles, and just add safeguards in them to not build everything everywhere, or perhaps we should avoid extracting all sources, for instance i915 sources on ppc64. I don't know if this is worth the effort though.
Comment Actions
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.
You have added all the sources to the pkg-plist, but you don't always install all the sources, it's dependent on the architecture. This works on amd64, since all sources are used there, but not on other platforms.
Hmm, I thought I matched what I do. I always install 'drivers' and 'include' which contains the bulk of the sources. The only conditional bits are the subdirectories that contain the module Makefiles, and those
are conditional (e.g. i915/Makefile)You are right, I just didn't see it the first time, sorry for that. You probably have to give the same treatment to amdgpu and amdkfd as you give to i915 and vmgfx well though, since they aren't built on i386, and other architectures.
It feels a bit like we need to make a decision, either we install all the sources, including makefiles, and just add safeguards in them to not build everything everywhere, or perhaps we should avoid extracting all sources, for instance i915 sources on ppc64. I don't know if this is worth the effort though.
I think the top-level Makefile already DTRT and only descends into relevant subdirectories. I think trying to split up the raw sources would be a big PITA and that excluding a handful of Makefiles is probably not worth it, so would be fine with just installing all of the Makefiles and sources always.
Comment Actions
Agreed. From a ports perspective, this is usually not very hard to get right, and the tools we have (poudriere, check-plist, ...) are quite good at helping out.
You have added all the sources to the pkg-plist, but you don't always install all the sources, it's dependent on the architecture. This works on amd64, since all sources are used there, but not on other platforms.
Hmm, I thought I matched what I do. I always install 'drivers' and 'include' which contains the bulk of the sources. The only conditional bits are the subdirectories that contain the module Makefiles, and those
are conditional (e.g. i915/Makefile)You are right, I just didn't see it the first time, sorry for that. You probably have to give the same treatment to amdgpu and amdkfd as you give to i915 and vmgfx well though, since they aren't built on i386, and other architectures.
It feels a bit like we need to make a decision, either we install all the sources, including makefiles, and just add safeguards in them to not build everything everywhere, or perhaps we should avoid extracting all sources, for instance i915 sources on ppc64. I don't know if this is worth the effort though.I think the top-level Makefile already DTRT and only descends into relevant subdirectories. I think trying to split up the raw sources would be a big PITA and that excluding a handful of Makefiles is probably not worth it, so would be fine with just installing all of the Makefiles and sources always.
I'm OK with this. Perhaps then i915/Makefile and vmgfx/Makefile should be installed in all cases, mostly for completeness and/or symmetry or something. :)
| graphics/drm-current-kmod/Makefile | ||
|---|---|---|
| 107 | You can use COPYTREE_SHARE | |
| graphics/drm-current-kmod/Makefile | ||
|---|---|---|
| 78–80 | It doesn't hurt to always create an obj dir, and if we turned this into a Uses/kmod.mk thing where we say 'USES= kmod=obj', I suspect we would just leave it always on as it wouldn't be worth the extra .if's to make it optional. I could make it optional if you wanted, though the MAKE_ENV above also has to be optional (and at that point you might want to wrap it in a single .if vs using pre-build-SOURCE-on) | |