> On Sat, 29 Mar 1997 Eric.Schenk@dna.lth.se wrote:
>
> > (Not to take away from Andi's point to much, the kernel is growing
> > and we should probably take a look at the reasons.)
>
> Has anyone ever considered making some form of linker that would allow
> compiled modules to be statically linked into the kernel, rather than having
> them as an integral part of the kernel source.
>
> Allowing them to be statically linked would allow them to be used during
> the boot process, whilst they could still be compiled separately (ie from
> separate source trees).
The problem is the module_init sections which must be called, sometime
with a command line.
Something close would be a minimal kernel with initial ram disk and only
romfs, which would contain insmod and the modules, and have a linuxrc that
would simply execute insmod on each file ending with .o (including extfs
and/or either scsi, ide or network disk drivers for the ultimate root
device). A thin insmod could also be written. romfs is really small, and
the ramdisk space is returned (I think) when the boot proceeds.
Now that 2.1.31 comes up (fairly stable after fixing several minor
problems), I will probably be trying to do something with this.
One problem is the existing kernel tree structure. ntfs and hfs
(macintosh) are totally separate, and I can compile them separately. I
cannot cd to fs/ufs and type make modules and have it do the same things.
It would also be nice if ipv4 was also available as a module (since it is
very large, but except for nfs root apps it could be loaded by kerneld).
Another approach which would remove the differences between modules and
internal would be to add an internal insmod to the kernel image itself,
with the .o file and a command line for each appended to the image and an
end-of-modules tag, so the kernel would link itself after initializing the
internal devices. So in the build, it might be something like a series of
commands like "cat modules/ext2.o >>vmlinux".
tz@execpc.com
finger tz@execpc.com for PGP key