[ 7.209578] calling snap_init+0×0/0x2a @ 1
[ 7.215488] initcall snap_init+0×0/0x2a returned 0 after 72 usecs

What is this stuff doing built into the vmlinuz? This stuff is a prime candidate for being modular, given that not everyone needs it. (I’ll bet a majority of users don’t even know what it is, let alone ‘need’ it).

This is defined in net/802/psnap.c Looking at net/802/Makefile, we see this gets built providing one or more of the following CONFIG options are set..

obj-$(CONFIG_LLC) += p8022.o psnap.o
obj-$(CONFIG_TR) += p8022.o psnap.o tr.o
obj-$(CONFIG_IPX) += p8022.o psnap.o p8023.o
obj-$(CONFIG_ATALK) += p8022.o psnap.o

Lets take these one by one.
Here’s where the fail begins. In the Fedora kernel, we had CONFIG_LLC set to =m. But something ends up overriding that decision, and making it a built-in. [note to self: make oldconfig shout when this happens]. Something must be ‘select’ing it somewhere. There’s actually quite a few things that do. But it turns out that the culprit in this case is CONFIG_TR. Wait, tokenring support is being built-in for every user ?
Afraid so. And why this happens is a bit tragic.

Looking at the definition of CONFIG_TR in drivers/net/tokenring/Kconfig is enlightening.

menuconfig TR
bool “Token Ring driver support”
depends on NETDEVICES && !UML
depends on (PCI || ISA || MCA || CCW)
select LLC

The ‘bool’ being the key problem here. Because TR ends up being built-in, all its dependencies and everything it selects also become built-ins. Changing this to a tristate solves this, and LLC remains modular.

Problems like this are why I really loathe the ‘select’ statement in kconfig.

The initcalls mentioned above were _tiny_ in comparison to some of the more obvious bloat, but there’s a bunch of low-hanging fruit in there like this which on first sight just leaves you wondering ‘wtf?’.

Hidden initcalls. is a post from: codemonkey.org.uk

No related posts.