Re: kernel libraries and dead code in MODULAR kernels

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

(Coming back to the original post.)

On Mon, Aug 31, 2015 at 10:55 AM, Dennis Ferguson
<dennis.c.ferguson%gmail.com@localhost> wrote:
> I've been compiling the same kernel configuration with and without
> options MODULAR and noticed that the MODULAR kernels have a not
> inconsiderable amount of code that is called neither by the kernel
> nor any of the modules.  I've appended a list of the global symbols
> from libkern.[ao] that end up being included in amd64 mostly-GENERIC
> modular kernels that have no callers and are omitted from non-modular
> kernel builds.
>
> The reason for this is that while non-modular kernels build a libkern.a
> from which only code that is actually called by something is loaded into
> the kernel, modular kernels instead build a libkern.o from which everything
> is unconditionally included.  While I understand why this is done (everything
> is included in case the separately-compiled modules need it) it causes
> a difficult problem if you would like to have a modular kernel without
> the dead code.  A few of those functions are in fact no longer used and
> could just be eliminated from the build, but the rest seem to end up
> there either because their use depends on configuration options which may
> or may not be defined, or they are members of a library that is also used
> in user space that has a richer API there than the kernel makes use of, or
> the use of particular functions (e.g. in the runtime library) is dependent
> on the architecture being built.

Yes, finding unused functions is hard.  Not only in libkern, but also
libc, or variables in abandaned `Makefile.kern.inc'.  Removing one
needs so much mental energy (especially when those picky wandering).

> While it would be possible to go through
> these and subset what is built for each kernel by options and architecture
> this is a whole lot of work, and a maintenance headache, compared to just
> compiling a few extra files and letting the loader figure out what the
> kernel it is linking actually wants.

My plan is to split kernel subsystem modules (or components in RUMP
term) into granular and define their dependency in config(5).  At this
moment, there is no concept to "depend on a library" there.

Modular dependency doesn't help to find dead code in modules (of course).

> The particular reason I'm concerned about this is that I am now loading
> the kernel against additional libraries with APIs the kernel won't make
> full use of and don't want to make the dead code issue worse, but I've
> found that maintaining the subsets the kernel does use to be quite
> painful and annoying, particularly for one library where the subset
> depends on the architecture being built.  I wouldn't mind going through
> at the end and subsetting the files which are never going to be used out
> of the kernel build to save a bit of kernel compile time, but for things
> that are option- or architecture-dependent this is way too complex to be
> worth the modest savings in build time.  There should be a better way to
> keep the kernel free of dead code.

You and others understand limitation of dynamically loading kernel
module; everything page aligned and backing pages are not shared.
These are costs to pay for flexibility.  Otherwise you go for built-in
modules.

If your concern is memory usage, help to improve kernel build and
modularity so that you can easily find unnecessary modules and
"relink" your kernel quickly.

> I do notice that for modular kernels the modules are built before the kernel
> is.  Is there no way to harvest the undefined global symbols from the modules
> and include these to force the kernel link to resolve them?

I don't think there is one, even in userland.  Dependency is per-library/module.

> Then libkern
> could go back to being libkern.a, with the bonus that using something in a
> module that the kernel doesn't have would cause a complaint when the kernel
> is loaded.

I agree that dead code is libkern should be investigated, but again, I
don't think there is no easy way to know what is *not* used.