Debian Suspend2 patch, mkinitrd / mkinitramfs ?

[Karl Hegbloom <hegbloom@pdx.edu>]

I'm looking at the stuff that Martin Krafft did for the Debian
mkinitrd setup to go with the kernel-patch-suspend2 (Debian
experimental) enabled kernels.  Nice work, Martin; I did not know you
could add conffiles to a kernel like that with a patch.  Very good.

Many of the things being done by the mkinitrd script
(/usr/share/doc/kernel-patch-suspend2/mkinitrd-script) are indeed
kludgy.  On my laptop, I'm doing similar things to make resume happen
for my hand compiled suspend2 kernels.  I started from the same source
Martin began with, the www.suspend2.net WiKi.

I also have a script that adds 855resolution and a script to run it to
the initrd, since my laptop with i855GM came with a 1400x1050 LCD
(probably by mistake -- the manufacturer spec says 1024x768 -- I
lucked out; the X server log told me what it really is) but the VBIOS
has no mode for it.  Additionally, the Linux mtrr system sets up the
caching incorrectly, and I must add a script that sets the mtrr
correctly; otherwise, the machine runs very slowly when it has 1Gib
RAM installed and CONFIG_HIGHMEM is enabled.

The thing is, that due to the design of mkinitrd and the standard
linuxrc it ships with, several of these mkinitrd scripts need to
modify the linuxrc script.  I must be careful to ensure that they
happen in the right order.  For instance, the mtrr hack must be first,
and the 855resolution hack must happen prior to resume from suspend,
or the X server can't switch back to graphics mode, and bails out.

What would fix this is to have the linuxrc script run some _early_
hooks from a 'run-parts' style directory.  I think they should be able
to run between the "call /loadmodules" and the "call /script", but
certainly _before_ the "do_swsusp".

Perhaps the "do_swsusp" should be extended to support Suspend2?  It
really is superior in several ways to the suspend already built into
the kernel.  I certainly hope that Suspend2 eventually is merged into
the mainstream kernel.  I believe they are working toward that goal
right now.

Q: Is there a revision control repository of the initrd-tools that I
can use to keep track of it's development, especially if a transition
to initramfs is planned?

I tried to change the mkinitrd command to a shell script that created
a compressed CPIO archive, but it did not work right.  The
855resolution hack did not seem to "take", but worse, the 'mtrr' hack
did not work... I think it's becuase the kernel does it's thing after
the initramfs is finished.

-- 
Karl Hegbloom <hegbloom@pdx.edu>