New kernel configuration system and modules

Considering the date of the article (2007) I'm tempted to say it's pretty much obsolete. To some extend anyway.

This even gets reflected if you check the chapter on Building a kernel in the FreeBSD developers handbook. In short it speaks of 2 ways to do this; the 'traditional' way which involves config(8) and the 'new' way which is basically the procedure as described in the handbook.

Also note "Up to version 4.X of FreeBSD this was the recommended way to build a new kernel." (about using config).
 
Yes, I saw the date, but thought that somebody is working on improvements here. What I am missing, is a clearer distinction of the modules available/being built. When building Linux kernels it is much more clearer what is available as a module, and the config script lets the user choose between module or kernel. Something similar would be nice for FreeBSD.
 
All drivers are built as loadable modules unless you have a WITHOUT_MODULES set in make.conf. The decisions to build or not to build something are done in the Makefiles in the source tree, the config(5) file plays no part in which drivers get built or not. The device/nodevice directives in the config(5) file affect only what drivers are linked directly to the kernel executable.
 
Of course, I know this. But what I don't know is: Are all options/devices available as a module?
 
vanessa said:
But what I don't know is: Are all options/devices available as a module?
Click to expand...
To my knowledge they are. You're more likely to come across the other kind of situation where a module can't be embedded in the kernel.

Just for the record; note that in the end there isn't much difference between building a component as an individual module (*.ko file) or embedding it in the kernel. In the end both components will still be treated and loaded in the same way.
 
vanessa said:
Of course, I know this. But what I don't know is: Are all options/devices available as a module?
Click to expand...

kldstat(8)() provides information about components that were loaded dynamically (see LKM as an introduction). If your kernel was built with INCLUDE_CONFIG_FILE option (enabled by default in GENERIC kernel), then you can see the static components using config -x /boot/kernel/kernel. See config(8)() for more details.

Note that the modules can also be loaded from the loader(8)() before the kernel starts, either automatically (through /boot/loader.conf) or by hand using the kldload(8)() command. Also read the section 9.4 Kernel Drivers, Subsystems, and Modules of the FreeBSD Handbook.
 
Very useful tips, however I still can not say upfront if commenting out an option or device will result in a module built automatically or in a missing functionality. This information (which parts of the kernel are available as modules) must be available somewhere ... Isn't it?
 
vanessa said:
Very useful tips, however I still can not say upfront if commenting out an option or device will result in a module built automatically or in a missing functionality. This information (which parts of the kernel are available as modules) must be available somewhere ... Isn't it?
Click to expand...

Please, read the section BUILDING THE KERNEL included in the make.conf(5)() man page. Or better, use /etc/src.conf to prevent the building of modules. See man src.conf for details.

So you can combine both, e. g. a custom kernel that only includes what you explicitely specify, and src.conf(5)() to avoid building of modules you're intendedly not going to need.
 
I am aware of the MODULES_OVERRIDE and WITHOUT_MODULES variables. Exactly therefore one needs to know the availability of code as a module. How could you otherwise decide what to put to those two variables?
 
Considering that most kernels are based on GENERIC it would of course help to study kldstat up front before configuring your kernel configuration. Another location to look into is /usr/src/sys/modules.
 
cpu82 said:
I think the contents of WITHOUT_MODULES should be the short names of the directories in /usr/src/sys/modules, basically remove the usb/ prefix you have on some of them. So if you put ulpt instead of usb/ulpt would be fine.
Click to expand...

This is exactly how I am doing it now and it works despite the fact that it is a kind of guessing instead of knowing.
 
You must log in or register to reply here.
Back
Top