On 17.02.2014 23:48, Florian Fainelli wrote:
There are multiple reasons:
- LINUX_UNAME_VERSION is determined way before the actual kernel is
built, using $(LINUX_VERSION) which is set by platforms
Yes, I was confused by LINUX_VERMAGIC which uses files generated during kernel
build, but then
falls back to "unknown" when these are not present.
But the value of LINUX_UNAME_VERSION is used exclusively while installing
modules, so it
would in principle be possible to delay its usage until the kernel has been
built.
- back in the days when trunk supported 2.4 kernels, that file was not present
ok, for 2.4 kernels, we could fall back to the original generation.
- as the comment states in top-level Linux sources, this file might
not be present, and cannot always be relied on
I hadn't been able to find such a comment. In fact what I found is
# Read KERNELRELEASE from include/config/kernel.release (if it exists)
KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
and
# Store (new) KERNELRELEASE string in include/config/kernel.release
include/config/kernel.release: include/config/auto.conf FORCE
$(call filechk,kernel.release)
which seem to indicate that the file isn't that unreliable any more.
The reason I am that insistent is, that it would be nice to support all of the
kernel's
version numbering schemes for custom kernels as well, including support for
loading modules
of such a kernel, e.g. the localversion files which are at the moment
officially unsupported
by openwrt.
Best regards, Nils
--
Nils Rennebarth
Software developer
bintec elmeg security GmbH
Mönchhaldenstraße 28
D-70191 Stuttgart
Germany
Tel: +49-711-900600-64
Email: [email protected]
www: www.bintec-elmeg.com
Location: Nuremberg, Local Court Nuremberg, HRB 25481<br>
Managing Director: Bernd Büttner
--------------------------------
The information contained in this e-mail has been carefully researched,
but the possibility of it being inapplicable in individual cases cannot
be ruled out. We therefore regret that we cannot accept responsibility
or liability of any kind whatsoever for the correctness of the
information given. Please notify us if you discover that information is
inapplicable.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
