Kernel configuration options

[Bernardo Innocenti]

John Richard Moser wrote:

>> Please, build a kernel with the changes you consider useful,
>> and make it available somewhere, along with your proposed
>> config patch.  Please make sure that the resulting kernel
>> also still works on QEMU and VMware.
>>
> 
> The base hardware drivers built in supports qemu and vmware?

Yes, but it doesn't take that much.  It's probably just a
pci IDE controller and the vesafb.


> Looks like I gotta read up on the wiki about how to rebuild the kernels 
> (again).  It seems I can alter Grub to do what I want afterwards though. 
>   (Do I need a developer's key or smth?)

Yes, you do need a developer key.  What is an smth?

Rebuilding the kernel RPM is less than trivial.  You may
prefer just building the kernel and then copying it on the
target with a stupid script like this one:

---8<---
dest=18.85.46.119
stagedir=stage

#vservers
destdir=/versions/boot/current/boot

#sane
#destdir=/

set -x
mkdir -p $stagedir/boot
make INSTALL_MOD_PATH=$stagedir modules_install
make bzImage
cp -a arch/i386/boot/bzImage $stagedir/boot/vmlinuz
cp -a System.map $stagedir/boot
tar -C $stagedir -czf - . | ssh root@$dest tar -C $destdir -xvzf -
---8<---


>> Extra bonus points if you can give hard numbers on memory
>> saving and performance gains.
>>
> 
> Black art ;)

Well, "size vmlinux" may be a lower bound approximation
for the memory saving.  Combined with some /proc/slabinfo
magic you'd get closer.

As you say, performance is hard to measure.  Shell scripts
tend to be good kernel benchmarks because they create lots
of processes, file descriptors, and do a lot of I/O.

>> I'd keep the debug symbols (which shouldn't cost any memory
>> at runtime).
> Possibly not.  The kernel runs inside one giant huge page doesn't it? 
> 4MiB read-write-execute...

Not on the Geode: we don't have MTRRs, so I guess the kernel
is being mapped by 4KB pages.

But anyway, aren't the symbols in a separate ELF section?
So probably they end up in the vmlinuz binary too, but
I've not checked.


>> Because of this, I think all the modules required for booting
>> off jffs2 and ext3 need to be linked in :-(
> 
> I think you can omit booting off ext3 for the final product.

Hmmm, people may like to boot off USB and SD, wouldn't they?
We're talking about a very small saving anyway...


> There is load-time consideration to be made about loading everything as 
> modules (camera, USB, mouse, all of networking, sound, etc) and leaving 
> the essentials (flash, display, keyboard, jffs2).  Even if you leave 
> networking and all the 100%-always-loaded modules compiled in, however, 
> there's no need for things like 30 types of file systems.

We still have plenty of places where we could recover several
*seconds* of boot time with just minor changes.  So I don't think
we should worry too much about module load time, which is probably
very fast.

In my experience, module load time is usually dominated by the work
being done in the init function, which sometimes involves sleeping
or performing slow I/O (i2c, serial, USB...).  This time would also
be spent in the monolithic kernel.


> I'd personally leave out ipv4 and ipv6 and just load them at boot time; 
> I'd rather not have ipv6 loaded right now, and ipv6 infrastructures 
> should run without ipv4 (some apps will probably complain about no 
> 127.0.0.1...); but this is just nitpicking.

I agree with you.


> Really I like a tiny core kernel and a bunch of modules but as
> I said, increases the time needed to boot.

I once again agree with you, except that I don't think
the load time increase will be problematic on the XO.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/