LWN: Comments on "In brief"

localmodconfig

BobRobertson — Tue, 22 Sep 2009 19:49:48 +0000

I found out about this after posting a "wish list" to lxer.com which
included building a kernel .config that had only the actually used modules
compiled in, and everything else as loadable modules.

I'll add my own Thank You to the list.

In brief

kabloom — Thu, 03 Sep 2009 20:35:39 +0000

Both of those are a bit of overkill. Why create an executable to generate the data, when a file will do.

In brief

dlang — Tue, 25 Aug 2009 23:09:17 +0000

if this just executes lsmod and parses the result, then the user can create a lsmod earlier in their path that echo's the results from a different box

or you could allow the user to specify a command to get the data (defaulting to lsmod if nothing is specified)

In brief

nevets — Tue, 25 Aug 2009 23:01:20 +0000

Yeah, that looks like we can add an enhancement. Perhaps add a "make LOADED_MODULES=embedded.lsmod localmodconfig", where embedded.lsmod is a filename holding the modules of the embedded device. Or have it use an environment variable to find the list of modules. If the environment variable does not exist, then it uses lsmod or /proc/modules. It currently does lsmod, but perhaps it should use /proc/modules directly.

Thanks.

In brief

mb — Tue, 25 Aug 2009 21:01:28 +0000

Well, but many small and embedded devices don't even have make or perl. So isn't there some way to tell the script to look somewhere else than /proc/modules (or wherever it looks into)?
So I could simply scp the modules list from the embedded machine to the build host and do the rest on the big machine.

localmodconfig

dirtyepic — Tue, 25 Aug 2009 01:35:58 +0000

that's the only one i can think of. i was mistaken about the cpufreq stuff of course. :) nice job, btw, this is something that was sorely needed.

local*config in Linux Next

nevets — Tue, 25 Aug 2009 00:39:36 +0000

local{mod,yes}config is now in the master branch of Linux Next:

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

Play with it and report anything that breaks.

Note, if you are using git, then you can do the following as well:

git remote add next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git remote update
git checkout next/master
make localmodconfig
git checkout <previous branch>

Now you have a streamlined config, even if you do not have the option in your current development branch.

localmodconfig

nevets — Mon, 24 Aug 2009 14:21:11 +0000

If there's a way to know about these, then certainly let me know. Email me at rostedt@goodmis.org. The localmodconfig is a start. But if we are missing necessary modules to boot the kernel, then we need to find a way to fix that.

localmodconfig

ABCD — Mon, 24 Aug 2009 02:19:48 +0000

> Anything that's loaded at boot is probably still loaded.

That usually isn't true in the special case of the microcode module, as the various distribution's init scripts generally load the module, update the microcode, then immediately explicitly unload the module.

localmodconfig

mjg59 — Sun, 23 Aug 2009 22:17:06 +0000

We don't generally automatically unload unused modules these days, especially since there's no good way to tell the difference between an unused module and one that's in use but has a reference count of zero. Anything that's loaded at boot is probably still loaded.

localmodconfig

dirtyepic — Sun, 23 Aug 2009 21:57:05 +0000

and microcode built as a module is loaded once during boot to update the microcode, and then immediately unloaded, so the answer would be "no". I'm guessing things like cpufreq modules that aren't currently in use would also be missed.

In brief

nevets — Sun, 23 Aug 2009 17:11:16 +0000

Yes exactly. It is just like the other "make *config". It only creates a config file and nothing more. I've used it on embedded boards to get a proper config. I would NFS mount the source, log into the embedded device, cd to the NFS mounted directory and run the "make localmodconfig" (well this is actually a lie, since I really just manually ran streamline_config.pl, but this should also work), and then built the resulting config on a faster box.

localmodconfig

nevets — Sun, 23 Aug 2009 17:07:29 +0000

It catches all modules that have been loaded. Anything listed in 'lsmod'.

In brief

jzbiciak — Sun, 23 Aug 2009 03:21:31 +0000

It looks like all this make target does is generate the .config. You'd still have to build the kernel and modules afterwards. (At least, that's the impression I got from the linked email.)

In brief

rvfh — Sat, 22 Aug 2009 17:26:45 +0000

I suppose you can do local*config on the low-power machine and interrupt it when it starts compiling, then copy the .config file accross. Make sure you have the right compiler and compiler options though...

In brief

dlang — Sat, 22 Aug 2009 10:28:42 +0000

do the local*module commands have some way of pointing you at a file from another server instead of (I assume) /proc/modules?

there needs to be some way to gather the info from one (probably low-powered) system and taking it to another system to actually do the build on.

localmodconfig

dirtyepic — Sat, 22 Aug 2009 04:09:06 +0000

i'm guessing this wouldn't catch modules that are dynamically loaded when needed, like, off the top of my head, microcode?

In brief

eparis123 — Fri, 21 Aug 2009 02:05:24 +0000

I really like the idea of the new option. Saves a lot of time wandering through the huge list of kernel options

Helpful localmodconfig

sjayaraman — Thu, 20 Aug 2009 16:59:29 +0000

Kudos!

I think Steven Rostedt posted earlier a perl script to do this called streamline-config.pl which was useful. This is even better - making it part of the build system!

Yay for localyesconfig

alex — Thu, 20 Aug 2009 09:25:59 +0000

Props to Steven Rostedt for implementing this. I'd been mulling over the usefulness of this option ever since I built a kernel for my Atom powered netbook which as you can expect takes a long long time. I suspect it will still take a while but at least a while compiling useful stuff :-)

Low-memory mapping - core fixes

jamesmrh — Thu, 20 Aug 2009 01:44:06 +0000

FYI, these changes are currently being merged into F11 and F10 (rawhide will pick them up automatically), and new kernels should be out v. soon.

Addressing this at the design level produces the most flexible result:

- the sysctl (mmap_min_addr) cannot be overridden at all by MAC security policy (e.g. SELinux)

- it can only be overridden with CAP_SYS_RAWIO

- if the sysctl is disabled to allow e.g. wine to run, MAC security policy can be used to add further restrictions to ensure that only wine can perform the mapping, and nothing else. i.e. running wine does not mean degrading security for the entire system.