Why would you NOT want to customize your kernel?

E

Ed_Flecko

From what I've read, it's pretty simple to customize your kernel. Since it seems like there's a lot of great reasons to do so (faster boot time, better resource utilization, possibly better system security, etc.), I'm just wondering why some (or many) people tend to shy away from doing it? Maybe many people's attitude is the old "if it ain't broke...don't fix it"?

:)

The only compelling reason that I've found so far is just that keeping your system patched and updated is a little different, but that's not that big of a deal with a custom kernel, is it?

Thank you,
Ed
 
Depends on what is meant by "customizing". Removing rarely-used modules is no big deal. It does not save much space or time, but generally is not a problem. The GENERIC kernel is made to run on almost any system, and that can be valuable. Build a kernel with CPUTYPE=corei7, and it will only run on machines that support those features.
 
By customizing I mean both removing rarely-used modules and also carefully enabling/disabling features that are specific to the machine it's running on as closely as you can.

Ed
 
If you stick with a GENERIC kernel, you don't have to compile the kernel when doing a binary upgrade with freebsd-update. I assume you were alluding to this when you said,
Ed_Flecko said:
The only compelling reason that I've found so far is just that keeping your system patched and updated is a little different...
Click to expand...
It's not a big deal to compile the kernel, but if you have many systems to upgrade, it can make your life easier to avoid compiling.
 
One of the real reasons to use a custom kernel is on a memory restricted system such as a machine that can't use the amd64 version of FreeBSD and that has less than 512MBs of RAM. Then it really helps avoiding kernel memory exhaustion to remove everything that is not used. There's also the issue of KSTACK_PAGES on i386 version of FreeBSD if you intend (unwisely I might say) to use ZFS on the system, on i386 you must recompile a custom kernel with increased KSTACK_PAGES to get ZFS working in the first place.
 
wblock@ said:
Build a kernel with CPUTYPE=corei7, and it will only run on machines that support those features.
Click to expand...
Where can valid CPUTYPEs for the kernel configuration file be looked up in the documentation? And yes, I tried to find it.
/usr/share/examples/etc/make.conf does mention it, but I suppose that is a different thing, isn't it?
 
Maybe if you run one of a few machines. I run dozens of machines that vary in spec. What would I benefit by building custom kernels for every one?

Boot time might improve by a few seconds, but I only reboot every few weeks or months and it takes about 30 seconds. If I was actually using enterprise hardware it would be even less important as those machines can spend several minutes in BIOS so a few seconds on kernel boot is irrelevant.

Resource usage difference would be mimimal. The kernel may reduce in size slightly but not exactly hundred of megabytes. Any modules in the kernel that weren't being used wouldn't be doing anything, just using a bit of memory.

For extra modules (zfs/pf/etc) I just load the modules in /boot/loader.conf. Far more convenient for me than recompiling the whole kernel.

I'd be intrigued if someone could come up with an actual security reason. In general any security issue in GENERIC should be patched as a security advisory.

On the plus side the kernel isn't tied to any particular system (in case I need to move the disk due to hardware failure) and most importantly I can apply binary updates with freebsd-update().

I don't really see that I gain anything. I would argue the opposite, why do people bother with custom kernels unless necessary (or you want to run STABLE/CURRENT)?
 
Customizing Kernel is good, I'm not against this. However, in my case, I have one real machine (server) and few virtual machines: 2 updated with latest RELEASE branch i386 and amd64, 2 with 9.x-RELEASE i386 and amd64, 2 with 10.x-RELEASE i386 and amd64. All with the GENERIC Kernel and updated/upgraded using binaries (with freebsd-update).

The server machine has an original Intel Atom motherboard (with 9.3-RELEASE), so I think I gain not much performance compiling a custom Kernel, essentially it's a DNS and web server, with other secondary daemons and a small NAS.

In the past, I compiled a custom Kernel, before version 9 to get VESA driver for display, when upgrading the system a new kernel must be compiled and also with patches (patch level update) if the Kernel is touched. Call me lazy, recompiling the Kernel, also for few machines like I have, is a bit annoying, if there are no good reasons to do that. The only reason I see is on machines with version 10.x with vt driver to change the screen resolution, but they have a DE installed, so I can leave with 640x480 resolution in console, and when in console I go remotely, so the console resolution is not a matter. It's only a matter when the system starts in single user mode. Since version 9 (some years now), FreeBSD never started in single user mode, and I have care only for the server machine, the ones in VM (sometimes, very few times) close the window skipping the shutdown procedure and never restarted in single user mode (and never lost something).
 
The FreeBSD handbook has a decent Chapter on building a custom Kernel.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html

While there can be read "Why Build a Custom Kernel?" the OP asked why "NOT" to do so.

wblock@ said:
Depends on what is meant by "customizing". ....
Build a kernel with CPUTYPE=corei7, and it will only run on machines that support those features.
Click to expand...

Customizing a FreeBSD kernel is done by editing the kernel configuration file.
In such a configuration file
Code: 
CPUTYPE=corei7
is not valid and is causing this error:
Code: 
/usr/src # make buildkernel KERNCONF=TEST

--------------------------------------------------------------
>>> Kernel build for TEST started on Thu Jul 30 12:00:34 CEST 2015
--------------------------------------------------------------
===> TEST
mkdir -p /usr/obj/FreeBSD/src/sys

--------------------------------------------------------------
>>> stage 1: configuring the kernel
--------------------------------------------------------------
cd /FreeBSD/src/sys/amd64/conf;  PATH=/usr/obj/FreeBSD/src/tmp/legacy/usr/sbin:/usr/obj/FreeBSD/src/tmp/legacy/usr/bin:/usr/obj/FreeBSD/src/tmp/legacy/usr/games:/usr/obj/FreeBSD/src/tmp/legacy/bin:/usr/obj/FreeBSD/src/tmp/usr/sbin:/usr/obj/FreeBSD/src/tmp/usr/bin:/usr/obj/FreeBSD/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin  config  -d /usr/obj/FreeBSD/src/sys/TEST  -I '/FreeBSD/src/sys/amd64/conf' '/FreeBSD/src/sys/amd64/conf/TEST'
/FreeBSD/src/sys/amd64/conf/TEST: [b]unknown option "corei7"[/b]
*** Error code 1

Stop.
make[1]: stopped in /FreeBSD/src
*** Error code 1

Stop.
make: stopped in /FreeBSD/src

Regarding make.conf(5) in the past there was a consent that one is usually better off not editing this file, although there is an option CPUTYPE that can be set. But /etc/make.conf does not configure a FreeBSD kernel.
 
My opinion regarding the OP's question is, if you have good reasons for customizing the kernel, than you need to do it and comfort is not a valid reason for refusing.
If you have no reasons then don't do this at home. :) It's just that simple.
 
The only supported CPU type you can use in the kernel configuration file for amd64 is HAMMER, everything else is invalid. For i386 there are three options, I486_CPU, I586_CPU and I686_CPU. The cpu type has a very different meaning in the kernel config file than what you'd expect. It is there to turn on and off hardware platform specific features, not optimizations.
 
getopt said:
Customizing a FreeBSD kernel is done by editing the kernel configuration file.
Click to expand...

That is one interpretation. That is why I said
Depends on what is meant by "customizing".
Click to expand...
A GENERIC kernel built with a specific CPUTYPE is certainly different from the one that comes with an installer. It is custom in that sense. Some parts of it will run differently (in my case, taking advantage of extra CPU instructions). So it is customized in that sense.

There are many things that should not be done in /etc/make.conf. That includes setting CFLAGS, which are generally a problem. There are others that can be used if the user is willing to accept responsibility for them. For me, that includes setting a specific CPUTYPE on some systems. I've tested it for more than a few years, and for me, that customization of a kernel and limited loss of portability is worthwhile.
 
wblock@ said:
That is one interpretation. That is why I said A GENERIC kernel built with a specific CPUTYPE is certainly different from the one that comes with an installer. It is custom in that sense. Some parts of it will run differently (in my case, taking advantage of extra CPU instructions). So it is customized in that sense.
Click to expand...
Let's make it explict clear. There are no specific CPUTYPEs for arch=amd64 (INTEL corei7 belongs to amd64 and that is what you mentioned), there is HAMMER only. Your example was wrong and misleading because of "corei7".
There are valid CPUTYPEs for arch=386i but "corei7" is none of them.
And again make.conf(5) does not configure a FreeBSD kernel.
 
Ed_Flecko said:
By customizing I mean both removing rarely-used modules and also carefully enabling/disabling features that are specific to the machine it's running on as closely as you can.
Click to expand...
Seems pretty clear. My example of setting a specific CPUTYPE enabled features specific to the machine it was running on. It did not involve editing the kernel config file, which was not specified as part of "customizing". Which is why I said that it depends on how the user defines "customizing". Which loops right back around to the start of this message.
 
wblock@ said:
Seems pretty clear. My example of setting a specific CPUTYPE enabled features specific to the machine it was running on. It did not involve editing the kernel config file, which was not specified as part of "customizing". Which is why I said that it depends on how the user defines "customizing". Which loops right back around to the start of this message.
Click to expand...

Got your point, which is a Kernel can be customized by another method than editing the kernel configuration file and building a new kernel with it. I want to learn, what method you are referring to.

What I'm aware of is loading kernel modules with kldload(8) and unload modules with unkldload(8).

What I've learned so far is, that a built kernel could/should not be able to be altered while running.

I'd appreciate if you could be more elaborate on that what you mean by "customizing" a kernel and not meaning building a new kernel by that.
 
Patrick Bär said:
Because it's not necessary any longer, as FreeBSD can now use modules, that's why :)
Click to expand...

Read my reply above. The GENERIC kernel is still quite bloated with drivers for hardware that almost nobody uses, for example SCSI controllers from the 1990s or even if they are used the drivers could very well be moved to be module only.
 
The GENERIC kernel is ~20 MB on my 10.1 system. I'm all for moving more old drivers into loadable modules but it's going to make a tiny difference on a modern system; Possibly more applicable if you're using an embedded device with absolutely minimal hardware specs. I value a standard "off-the-shelf" system with supported binary upgrade path over a slight reduction in kernel size that will likely have no noticeable impact.

However, interestingly there's a MINIMAL config file which says the following in the commit message:
Code: 
New MINIMAL kernel config. The goal with this configuration is to
only compile in those options in GENERIC that cannot be loaded as
modules. [...] This is part of some work to get more things
automatically loading in the hopes of obsoleting GENERIC one day.
 
kpa said:
The GENERIC kernel is still quite bloated with drivers for hardware that almost nobody uses, for example SCSI controllers from the 1990s or even if they are used the drivers could very well be moved to be module only.
Click to expand...
Agreed, and I've wondered why the GENERIC kernel isn't stripped down more by default. The only reason I can come up with is some companies still use that stuff and want it compiled into the kernel for whatever reason. This is the main reason I use a custom kernel. I don't need nor do I want any of that stuff.

More directly related, /usr/share/mk/bsd.cpu.mk has more information on CPUTYPE and architecture.
 
kpa said:
Read my reply above. The GENERIC kernel is still quite bloated with drivers for hardware that almost nobody uses, for example SCSI controllers from the 1990s or even if they are used the drivers could very well be moved to be module only.
Click to expand...

So? He asked for reasons NOT to create a customer kernel. An answer he got :)
 
getopt, CPUTYPE in /etc/make.conf is a compiler option. It tell the compiler that it can and should use specific things supported by that CPU. Add that entry and rebuild the kernel, and although it still has the same devices, but the object code is built with (maybe) different instructions suited to that particular type of CPU.
 
getopt said:
wblock@, if that is true, what does that mean for crossbuilding world and kernel?
Click to expand...

Cross-compilers ignore CPU and optimization options that don't make sense with the target architecture. I should verify this but as far as I remember none of the custom compiler flags actually make it to the compiler command line when kernel code is compiled because the build system wants to keep a tight control on what options are used.
 
protocelt said:
Agreed, and I've wondered why the GENERIC kernel isn't stripped down more by default. The only reason I can come up with is some companies still use that stuff and want it compiled into the kernel for whatever reason. This is the main reason I use a custom kernel. I don't need nor do I want any of that stuff.
Click to expand...
I think it is still worth keeping a few MBs of extra in the kernel than compromising the "default support for legacy hardware". Yes, it is there, and yes, anybody can "compile a new kernel", but it is good to have.

If there is no security risks involved, and you are not trying to run FreeBSD on a minimal or embedded system, I see no point of removing the any support.
 
You must log in or register to reply here.
Back
Top