Hi All,
I have a requirement that the uname command produce a string with the HEAD
SVN-Revision number embedded in it.
The standard Linux build methods assume that the SVN tree is the same as the
build tree.
See ./trunk/build_dir/linux-<platform>/linux-<version>/Makefile (search for
"_localvar_auto")
and ./trunk/build_dir/linux-<platform>/linux-<version>/scripts/setlocalversion.
Together these update the
./trunk/build_dir/linux-<platform>/linux-<version>/include/config/kernel-release
with the SVN HEAD Revision number.
This assumption is not the true for openwrt, where the contents of the
build_dir directory is dynamically built, and not under SVN control.
I have modified the top-level Makefile to provide a new "$(SCMROOT)" variable
which specifies the root of the SVN tree: SCMROOT:=${CURDIR}.
The Linux-build Makefile was then modified to use $(SCMROOT) instead of
$(srctree).
This all works fine. Now "uname -a" shows the SVN-Revision number appended to
the kernel-release string, per expectations.
But there is a problem....
The kmod-<driver> packages are built before the linux kernel build runs the
setreleaseversion.
So the kmod-<driver> is build with kernel-version info which does not include
this new SVN Revision suffix.
When insmod is used to load the kmod-<driver> the operation fails because of
kernel-version mismatch.
If course I could enable the "force" option, but that defeats the nice version
checking this method should provide.
I could also rebuild the kmod-<driver> as a package after the main build, but
seems to an admission something is wrong with the build process.
Question:
While I can hack a solution, I would be much more interested in learning the
"best practice" for controlling the build order of kmod's.
My hope is there is some simple recipe for doing this.
Thanks,
Robin
This email may contain confidential and privileged material for the sole use of
the intended recipient. Any review, use, distribution or disclosure by others
is strictly prohibited. If you are not the intended recipient (or authorized to
receive for the recipient), please contact the sender by reply email and delete
all copies of this message.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
