Kernel modules ng_ether.ko and ng_gif.ko cannot be loaded if kernel is built with options VIMAGE and modules are built outside of kernel build enviroment (e.g. nanobsd & MODULES_WITH_WORLD): # kldload ng_ether kldload: can't load ng_ether: Exec format error kernel: link_elf_obj: symbol ifnet undefined kernel: linker_load_file: Unsupported file type Fix: Introduce new src.conf knob WITH_VIMAGE so modules can be built for such kernel and loaded successfully. How-To-Repeat: See above.
Forgot to note that tools/build/options/WITH_VIMAGE should be created also, containing two following lines: .\" $FreeBSD$ Set to build with the VIMAGE support. And regenerate src.conf(5)
My humble opinion is that whenever you have to build some modules separately from kernel (for whatever reason), then it's better to provide KERNBUILDDIR to the module build. Because you are absolutely correct that the kernel and the modules have to be compatible. -- Andriy Gapon
Hi! virtualbox-ose-4.3.6 built with virtualbox-ose-kmod-4.3.6 panices kernel at the moment of vboxnet initialization if kernel is built with options VIMAGE. We need WITH_VIMAGE make.conf knob at least for ports but several stock kernel modules like ng_ether.ko, if_gif.ko must be built with respect to VIMAGE and will benefit from new knob too. Please commit the patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/184176 Eugene Grosbein
Recently introduced linux64.ko also suffers from missing WITH_VIMAGE knob, it cannot be loaded into VIMAGE-enabled kernel by default and it cannot be rebuilt with this knob as it does not exist yet.
(a) it should be WITHOUT_VIMAGE as that is the current default and you need other places as well to properly add much an option. (b) it's a kernel config file option and not a build/make option; to my very best knowledge all user space changes were designed to be able to dynamically cope with VIMAGE (and really only libkvm comes to my mind currently) (c) and make.conf to me seems the entirely wrong granularity for this. (d) lastly see SRCS.* in HEAD and sys/conf/kern.opts.mk which is getting a lot closer to what you are looking for (along with a kernel build tree) though those seem to be driven from src.conf, which I hadn't realised; we should find people who understand what the design had in mind. I would love to have these things derived from a kernel config file really but I am staying out of that make foo.
Not 10.x nor 9.x have VIMAGE on by default and this PR was created in time of 9.2-STABLE. Also, I still do not see VIMAGE turned on by default for HEAD even, not in GENERIC nor in DEFAULTS. Anyway, it might be WITHOUT_VIMAGE, not big deal. > make.conf to me seems the entirely wrong granularity for this Of course, and this PR's subject says "src.conf", not "make.conf". I've mentioned make.conf by mistake in a comment. The fact is, kernel modules compiled outside of kernel build environment are incompatible with VIMAGE-enabled kernel currently for 10.2-STABLE too.
My PR.
I am going to close this as VIMAGE is shipping on by default in 12 for various architectures. VIMAGE is a simple kernel option. The build of out-of-tree modules need to match the kernel configuration and not a src.conf(5) option. https://svnweb.freebsd.org/base?view=revision&revision=339901 is a good way forward for building out-of-tree modules.