Thus spake Dann Frazier ([EMAIL PROTECTED]):
> 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.
Are there any major distros that don't include a .config file with their
kernel(s)? I know that SuSE provides a /proc/config.gz, which is
_really_ nice, that we could always check for first as it will always
match the running kernel.
> 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.
This is a difficult question.
Brain storming: dmesg freshly booted machine will tell us the order that
certain drivers were loaded, but not necessarily info for all devices.
I think some drivers may load silently.
However! It seems that I've never met a network or disk driver that
didn't record some info into the ring buffer. Maybe we can use that in
some way?
> 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.
Some systems now use /etc/modules also, or instead of modules.conf.
We may need to take that into consideration too.
-Brian
> -------------------------------------------------------
> 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
--
---------------------------------------------------------
Brian Elliott Finley Phone: 630.803.8183
GPG: 3FF8 D096 0E0C D3F3 29B7 6518 D20B 1931 10F8 EE52
---------------------------------------------------------
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
