Ubuntu Host Building Kernel Module
I've noticed on multiple occasions that oftentimes I will build a different
branch of OpenCPI after my system has been running for a while, and when
the test for the kernel module comes around, it will fail. The issue is
that /usr/src has newer linux headers than the current kernel that is
running.
I suspect these headers get updated/installed during the apt check at the
beginning of the deps script, but I am not sure.
I am also not sure what the solution should be:
- Error out of build when mismatch is detected
- Build against the currently running linux kernel headers
- Build against the latest linux kernel headers installed (current
solution)
Obviously the current solution causes me to reboot my machine, and re-build
to update. Maybe that's the best solution, though it doesn't tell me that
the mismatch occurred - I just need to realize what happened and take an
appropriate step to fix it?
As an ancillary question, is there a way to update just the kernel module
during the build? I am using ./scripts/install-opencpi.sh - is there
another script to run, or arguments that I can run to just re-build the
kernel module and test just the kernel module?
Thanks,
Brian
On 10/26/20 1:21 PM, Brian Padalino wrote:
I've noticed on multiple occasions that oftentimes I will build a different
branch of OpenCPI after my system has been running for a while, and when
the test for the kernel module comes around, it will fail. The issue is
that /usr/src has newer linux headers than the current kernel that is
running.
I suspect these headers get updated/installed during the apt check at the
beginning of the deps script, but I am not sure.
I am also not sure what the solution should be:
- Error out of build when mismatch is detected
- Build against the currently running linux kernel headers
- Build against the latest linux kernel headers installed (current
solution)
Obviously the current solution causes me to reboot my machine, and re-build
to update. Maybe that's the best solution, though it doesn't tell me that
the mismatch occurred - I just need to realize what happened and take an
appropriate step to fix it?
There are a number of checks in the kernel driver build that tries to
understand the difference between the running kernel and the most
recently installed one.
But perhaps they are too centos specific. We don't really take care of
dealing with building drivers for older kernels, although there is an
environment variable to force the issue.
What behavior would you want? A knob that forces the build to target
the currently running kernel?
The RPM installation machinery tries to be even more clever and rebuild
the driver at the time a newer kernel is rebooted.
As an ancillary question, is there a way to update just the kernel module
during the build? I am using ./scripts/install-opencpi.sh - is there
another script to run, or arguments that I can run to just re-build the
kernel module and test just the kernel module?
"make driver" in the root directory is the "internal" way to do it, but
that is not stable or documentable that way.
Jim
Thanks,
Brian
On Mon, Oct 26, 2020 at 1:46 PM James Kulp jek@parera.com wrote:
On 10/26/20 1:21 PM, Brian Padalino wrote:
I've noticed on multiple occasions that oftentimes I will build a
different
branch of OpenCPI after my system has been running for a while, and when
the test for the kernel module comes around, it will fail. The issue is
that /usr/src has newer linux headers than the current kernel that is
running.
I suspect these headers get updated/installed during the apt check at the
beginning of the deps script, but I am not sure.
I am also not sure what the solution should be:
- Error out of build when mismatch is detected
- Build against the currently running linux kernel headers
- Build against the latest linux kernel headers installed (current
solution)
Obviously the current solution causes me to reboot my machine, and
re-build
to update. Maybe that's the best solution, though it doesn't tell me
that
the mismatch occurred - I just need to realize what happened and take an
appropriate step to fix it?
There are a number of checks in the kernel driver build that tries to
understand the difference between the running kernel and the most
recently installed one.
But perhaps they are too centos specific. We don't really take care of
dealing with building drivers for older kernels, although there is an
environment variable to force the issue.
What behavior would you want? A knob that forces the build to target
the currently running kernel?
I suppose since it's a relatively simple thing, why not build the kernel
for all the sources installed? When running the test, it could check to
see which one matches the currently running kernel? Seems like that is a
way to be prepared for every situation, and building the kernel module is
basically nothing compared to the rest of the build process.
The RPM installation machinery tries to be even more clever and rebuild
the driver at the time a newer kernel is rebooted.
As an ancillary question, is there a way to update just the kernel module
during the build? I am using ./scripts/install-opencpi.sh - is there
another script to run, or arguments that I can run to just re-build the
kernel module and test just the kernel module?
"make driver" in the root directory is the "internal" way to do it, but
that is not stable or documentable that way.
Will this way be supported/documented in some way, or is this just for
information for now?
Thanks,
Brian