modules_enabled in kernel ELF note section
Folks, It would be nice if ELF kernel image holds "modules_enabled" value in note section which allows LIBSA to tell whether the target kernel is MODULAR or not. Toru Nishimura / ALKYL Technology
re: modules_enabled in kernel ELF note section
> It would be nice if ELF kernel image holds "modules_enabled" value in > note section which allows LIBSA to tell whether the target kernel is > MODULAR or not. modular kernels don't *have* to have modules loaded via the boot loader. so what i think you're really after is a flag that says "we want to try to load modules in the loader". .mrg.
Re: modules_enabled in kernel ELF note section
On Wed, Jan 12, 2011 at 01:59:42PM +1100, matthew green wrote: > modular kernels don't *have* to have modules loaded via the boot > loader. so what i think you're really after is a flag that says > "we want to try to load modules in the loader". We could have a note section that makes it easy to find out for the boot loader (a) wether the kernel is modular and (b) the list of modules it has built in. The loader could then drop any module requested in its configuration file if it is already part of the kernel, or drop the whole list if the kernel is non-modular. The boot loader could also construct an automatic list if it is not configured for any, which as only item includes the file system it found the kernel on. Martin
Re: modules_enabled in kernel ELF note section
> > It would be nice if ELF kernel image holds "modules_enabled" value in > > note section which allows LIBSA to tell whether the target kernel is > > MODULAR or not. > > modular kernels don't *have* to have modules loaded via the boot > loader. so what i think you're really after is a flag that says > "we want to try to load modules in the loader". Modular kernels have to have module(s) loaded via the bootloader if the kernels don't have builtin modules for the root file system, where the kernel is loaded from. All other modules can be loaded from the root file system after mountroot(). So necessary info might be "which file-system modules are builtin?" (though I'm not sure if options NFS_BOOT_DHCP requires bpf(4) module or not) --- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
"matthew green" points; a flag that says "we want to try to load modules in the loader". The most interesting part of module preload facility is to allow miniroot.kmod. This eliminates the necessity to build a separate INSTALL kernel which holds mdimage inside. Another possiblity is to have DDB symbol table as a module. This would wape out the awesome burdern of SYMTAB_SPACE maintaintance when LIBSA bootloader is made smart enough to do that. Toru Nishimura / ALKYL Technology
Re: modules_enabled in kernel ELF note section
"Izumi Tsutsui" said; So necessary info might be "which file-system modules are builtin?" LIBSA does heuristics to find rootfs type and then stats to see it can be loaded from a local or remote store. (though I'm not sure if options NFS_BOOT_DHCP requires bpf(4) module or not) The code segment does in-kernel socket creation and send/recv dialogue. Toru Nishimura / ALKYL Technology
Re: modules_enabled in kernel ELF note section
> > So necessary info might be "which file-system modules are builtin?" > > LIBSA does heuristics to find rootfs type and then stats to see it can be > loaded > from a local or remote store. It checks a file system type where the kernel is loaded (as sys/arch/i386/stand/lib/exec.c:command_load_kernel() does), not the root file system. (they are identical in most case though) Necessary info is "if the loaded kernel has modules for the file system." --- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
Izumi Tsutui points; It checks a file system type where the kernel is (to be) loaded It's a norm case that a target kernel is stored in rootfs, I think. Toru Nishimura / ALKYL Technology
Re: modules_enabled in kernel ELF note section
> The most interesting part of module preload facility is to allow > miniroot.kmod. This eliminates the necessity to build a separate > INSTALL kernel which holds mdimage inside. That's what i386 did and miniroot.kmod was loaded via boot.cfg(5) like distrib/i386/cdroms/installcd/boot.cfg.in in netbsd-5. (-current doesn't use miniroot.kmod and use cd9660 root fs) Modules loaded by the bootloader are handled in module_init_md() as x86/x86_machdep.c inside #ifdef MODULAR so if the kernel doesn't have MODULAR I think loaded modules are simply ignored. -- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
This eliminates the necessity to build a separate INSTALL kernel which holds mdimage inside. That's what i386 did and miniroot.kmod was loaded via boot.cfg(5) like distrib/i386/cdroms/installcd/boot.cfg.in in netbsd-5. (-current doesn't use miniroot.kmod and use cd9660 root fs) It's my routine to PXEBOOT i386/amd64 first, interrupt countdown immeediately while boot.cfg menu is shown, run "modules enabled" and "load miniroot.kmod", then type "boot netbsd" for all upgrade or fresh installation. ISO image is vnconfig'ed and NFS-exported on the install server side. It's a snap handy way for bulk net-install and disaster control. Toru Nishiumra / ALKYL Technology
Re: modules_enabled in kernel ELF note section
This eliminates the necessity to build a separate INSTALL kernel which holds mdimage inside. MODULAR miniroot.kmod would be benefitial to small embedded NetBSD products. miniroot.kmod is, in essense, a kind of "root on md0" switch. MODULAR-aware LIBSA can choose to switch the target md0 image whose content is stripped down userland. In these days, there is a growing marketing push of microSD for embedded products. Some SoC are even able to boot directly from socketed multi-giga-byte microSD media, removing soldered down NOR flash from PCB. When NetBSD LIBSA bootloader is made right, miniroot.kmod can be stored in the store as well as kernel image. It may become a standard way to make commercial embedded NetBSD product on HW which has microSD FAT store as a primary stroage. Toru Nishiumra / ALKYL Technology
Re: modules_enabled in kernel ELF note section
> MODULAR miniroot.kmod would be benefitial to small > embedded NetBSD products. miniroot.kmod is, in > essense, a kind of "root on md0" switch. options MEMORY_DISK_DYNAMIC ? > MODULAR-aware > LIBSA can choose to switch the target md0 image whose > content is stripped down userland. We have to move boot.cfg(5) support and loading module functions from i386/stand to MI libsa, I think. --- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
options MEMORY_DISK_DYNAMIC ? miniroot.kmod works in an automagical way. I'm afraid that it's a bad concidence to keep adding MD_HOOK_BOO to solve situations. We have to move boot.cfg(5) support and loading module functions from i386/stand to MI libsa, I think. I feel hesitated to do so since it's somehow "grub'ing" way to pursue imaginary (and not-existing) universal loaders and would limit creative imagination to florish. Scripting and even command line editing for debug would be possible and all heavily depend on targets to port and how to use it in field. Toru Nishimura / ALKYL Technology
Re: modules_enabled in kernel ELF note section
> > options MEMORY_DISK_DYNAMIC ? > > miniroot.kmod works in an automagical way. I'm afraid that it's a > bad concidence to keep adding MD_HOOK_BOO to solve situations. Fortunately MEMORY_DISK_DYNAMIC is already in options(4). > > We have to move boot.cfg(5) support and loading module > > functions from i386/stand to MI libsa, I think. > > I feel hesitated to do so since it's somehow "grub'ing" way to > pursue imaginary (and not-existing) universal loaders and would > limit creative imagination to florish. Scripting and even command > line editing for debug would be possible and all heavily depend > on targets to port and how to use it in field. We can still imagine more specific existing structures: - functions that load modules could be in MI as libsa/loadfile.c for kernels - bootinfo structures that pass module info etc. to a loaded kernel are MD (unfortunately) - some ports don't bother to implement getchar() (i.e. all args are passed via PROM prompt) - some ports cannot have tgets() (gets() with timeout) due to firmware limitation etc. - we cannot implement "timeout-then-default" method without tgets() - loading and parsig boot.cfg(5) functions could be in MI - banner, default, load, and module commands in boot.cfg(5) could be common - clear, consdev, more than one menu items (and format) commands in boot.cfg(5) should be optional per each port - some MI file system specific libsa sources already have knobs to return necessary module names for them (via FSMOD and FSMOD2) and we can update other ones Passing the default commands to a bootloader via boot.cfg(5) file is enough to make the bootloader load specific modules per boot media settings, and most ports can have such implementation, I think (though it's still imaginary). No idea what will modules_enabled help for us. --- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
On Wed, Jan 12, 2011 at 07:04:55PM +0900, Toru Nishimura wrote: > Another possiblity > is to have DDB symbol table as a module. This would wape out > the awesome burdern of SYMTAB_SPACE maintaintance when > LIBSA bootloader is made smart enough to do that. I'm sure the SYMTAB space fubar could be sorted by linking the kernel twice. After the first link, a script grabs the symbol table and works out how much space will be needed. Then you link again. I've done this in the past to include symbol lists is a 'kernel'. David -- David Laight: da...@l8s.co.uk
