Todo

[Adi Linden]

Hi,

> That's certainly a problem, and one which grows out of the kernel's
> monolithic architecture. The best you can do is make everything that
> might be optional a module, as you suggest below.

I have a question, how much code is added to the kernel for an option
build as module? Is all the code for a particular ethernet driver for
example contained in the driver module?

> > Another option would be to reduce the number of special purpose kernels
> > and insead build a highly modularized kernel with virtually all options.
> > Very similar to the stock RedHat kernel.
> 
> An embedded systems designer would have the same advantages that Red Hat
> has, too: by putting a selection of modules, not all of which are always
> needed, on a compressed initrd the final kernel RAM footprint might be
> a bit smaller.

The initrd is only required if the kernel is needed before mounting the
partition containing the modules (i.e. RAID, SCSI). pwlconfig would allow
to select which modules to make part of the filesystem.

> layer more often than some people change socks, and of course don't 
> document them. Going from 2.2 to 2.4 is reportedly not so traumatic as
> 2.0 to 2.2, but still...defer the pain if you can.

I am thinking of adding the 2.4 kernel as an enhancement in addition to
the latest 2.2.x kernel. I.e. the K-Net Router I am maintaining contains
modules that are available in binary only. So switching it to 2.4 isn't
an option. I wouldn't want to make future PeeWeeLinux releases useless for
a developer stuck with a 2.2.x kernel for some other reason. I will try to
switch to the latest 2.2.x kernel, though.

As I understand the 2.4 kernel contains some things that might make
embedded life much easier, like the virtual dev filesystem.

> Embeddix, I think. They have a utility which can look at an executable
> --or maybe a set of executables--which you propose to put in your target
> system, then construct a custom library containing only the stuff you
> really need. I think that's how it works. For good reason they call it
> 'lipo'. I've been trying to figure out how they do that. 'ldd' can tell
> you which libs an executable needs, but not which routines in the libs
> it links to.

To start I'd like to add a dependency check routine that merely lists libs
which are either needed and not present or present and not needed. Perhaps
with an option to update the package list automatically.

I've looked at tiny libs. But most of them require binaries to be compiled
against them. That would require compiling on the fly... maybe some day...

TTYL,
Adi






---------------------------------------------------
See the list archives at http://adis.on.ca/archives/
See the PWL homepage at  http://peeweelinux.com
---------------------------------------------------