I'd like to start a discussion on the design of the code that will
allow sis to use a known good kernel, and hopefully come up with
a modular API that will allow us to work in parallel to complete this,
and easily add new functionality in the future.
I've been calling this mkbootflavor, just to give it a name.
Here are the issues that I see this project having to deal with:
1) Generating an initrd mountable by the kernel
- Detect supported initrd fs types
- Build an initrd of the appropriate type
2) Setting up an appopriate /dev (we can't count on devfs)
- Determine what dev styles the kernel supports
(static /dev entries, devfs, udev in the future)
- Set up the initrd to work w/ the given dev type
(root=/dev/rd/0 vs root=/dev/ram, etc)
3) Determining what modules to load, and in what order, prior to install
4) Creating an easy to use tool around this logic
I'm a big fan of the SC methodology, so it'd be cool to do something similar.
A rough idea of what that means is:
InitrdFS::<fs>::footprint() -- can we use a <fs> type initrd?
InitrdFS::<fs>::build() -- create an initrd image of <fs> type
mkcramfs|dd/mke2fs/mount/cp
DevStyle::DevFS::footprint() -- can we use devfs?
DevStyle::Static::footprint() -- do we have to use static /dev files?
DevStyle::uDev::footprint() -- the future...
DevStyle::<dev>::config_initrd() -- if its static, maybe we just copy select
-- /dev entries from the host system. if
-- its devfs, we copy over the devfsd.conf
-- and add the code to mount it, etc
etc. This way, when new things come about (initramfs, udev, etc), we are
just adding a new module, instead of adding a bunch of ifthenelse stuff.
Depending on how we do things, methods like footprint() may end up being
a simple string matching - but encapsulating this is a good thing, so
we can easily change it in the future.
Opinions?
Ok - now onto the how this stuff could actually work.
There are two approaches I can see to dealing with the question of what
the kernel will support. We can either look at the config (assumes
we know we have the right config for the given kernel), or try to do things,
and see what works (assumes they are running the requested kernel, and we
know where its binary is).
In other words:
Create an ext2 filesystem & mount it - making sure no ext2 module gets loaded
vs.
Look for CONFIG_EXT2=y in .config
Either way, we have to make some guesses. For example, we can mount a
cramfs image or look for CONFIG_CRAMFS but we can't know for sure if its useful
as an initrd w/o trying to boot into it. But, if EXT2 is a module, and
CRAMFS isn't, we can make an educated guess that they probably have the
cramfs initrd patches. So, I vote for parsing the .config - its easier.
How do we switch between the possible /dev's?
At initrd build time, we
1) Leave a mark in the initrd (echo devfs > $initrd/etc/devtype) that we
can examine at runtime. ( if [ $devfstype == "devfs" ]; then devfsd; fi )
2) Copy anything we might need from the host system (static /dev entries,
devfsd.conf, etc)
Now the hard one - module order. Why does it matter? Well - its pretty
annoying when your install kernel will see your sym53c8xx controller first,
and your mptscsih controller second, but your runtime kernel does the
opposite. The sda you installed to is not the sda you're booting from,
and your system is unbootable.
I spent lots of time thinking about this, and
I still haven't come up with a great solution. But, maybe my ideas will
give someone else a great idea.
- mv /sbin/modprobe /sbin/modprobe.real, and make /sbin/modprobe
a shell script that keeps a log of module loads, and calls
modprobe.real to do the real work. But, this doesn't effect the
/sbin/modprobe in the system's initrd, so we'll never know the
order in which it loads modules.
- look at module symbol addresses in /proc/ksyms, and assume a
chronological order. i don't know how arch specific this is,
and there maybe corner cases, but here's some sample code.
this is quite likely very linux 2.4 specific - probably won't
work in 2.6.
#!/usr/bin/perl
open(KSYMS, "</proc/ksyms");
$last = "";
while (<KSYMS>) {
if (/\[(.*)\]$/) {
if ($1 eq $last) {
next;
}
print "$1\n";
$last = $1;
}
}
- another option is to ignore all modules but storage & net, and do
them in device-specific ways. how do you know which module maps
to /dev/sda? i don't have a good answer for that.
Once we have the list of modules, we can determine which ones reside
in drivers/net, and make sure those are loaded in the initrd. It'd
probably also be a good idea to copy over modules.conf, so we get
any weird options that may need to be passed.
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
