initrd question

[Doug Sutherland]

Greg,

> What concerns me the most is whether speechd-up 
> and speech-dispatcher are staticly built or  not.

You control this with compiler options -static and -shared.
You can determine this easily by checking the makefiles,
and change it if it's not the way you need it to be.

> My other concern is the amount of dependencies that the
> speech-dispatcher debian package seems to have.

I think you need to mess around with source if you want 
to achieve this goal. Build from source, examine the 
makefiles, and you'll know soon enough the dependencies.

> The other thing I wasn't sure about was what libraries I'd need to
> copy over to have everything (I.E. speech-dispatcher and alsa)
> working. 

This too becomes clear when building from source. I was
building alsa from source before it was included in kernel.
Now, the device drivers are in the kernel, but the libraries
are not, so alsa-driver is already done, you need the 
alsa-lib and alsa-conf. Alsa is a project, so there are many
things that may be available, the relevent question is what
is the minimal you need for your ramdisk. Don't think in 
terms of packages, build the core and check if what you
need works, add what's missing, there you'll find your 
dependencies. 

> My main goal after all would be to install a minimal
> distribution (even just the debian base system would be too big), the
> single purpose of which would be to boot, restore alsa parameters,
> start speech-dispatcher/speechd-up, load up support for the
> chipset/hard drive, and hand off control to the root fs, with software
> speech already running, and speaking things such as e2fsck running,
> and the rest of the boot process up until login and beyond of
> course.

Yeah, that's the best way to think of it. Rather than trying
to work on ramdisk first, work on the minimal distribution.
I would recommend make a partition to experiment with 
and build the minimal system there, once you have the 
various parts working it will be easy to determine how 
much space is required etc. Even if for some reason you
were not able to get it working as ramdisk you'd have a 
good rescue partition and could put that on all machines,
and also make a bootable iso file.

Handing off control to the real root fs is done with 
pivot root, which was designed for exactly this purpose.

> I'm not even going to throw compiling all sound card modules
> into the mix, the initial job of having this work would be hard enough
> as it is with just knowing what sound card is going to be used.

Well that's all kernel stuff, but it would be best to include
them all. What is a linux install disk? It's a ramdisk with 
generic kernel. That's the kind of kernel you want. It 
makes no sense to make it specific to your machine, 
you want a ramdisk that will boot on anything. That work
is already done, you can find a kernel set up that way, 
or use the config from one.
 
> I guess the other question to ask is would the initial amount of ram
> required for something like this, be a good enough of a trade off to
> have speech early enough in the boot process to hear the system on the
> hd booting but potentially not early enough to hear kernel panics?

The kernel cannot panic. Your alsa is a kernel driver. 
If it panics no sound. The annoying thing is that console 
output is available. Food for thought, if the goal is to be 
able to determine what went wrong, then a completely 
different approach would be to work on trapping that 
console output and putting it somewhere. Compared to
what you're proposing that is far less complex. Unix
was designed to be used from serial console. There 
must be a way to grab that output and log it somewhere
so you can find out what happened before you were 
able to hear it.

> Since the initrd ram does get released though, that may not be a big
> deal with the amount of ram your typical pc has these days.

Yeah, I have 1GB RAM and the entire linux system 
barely dents that.

If you really want to do this I would recommend looking
at the buildroot project. It builds root filesystems for 
booting linux from flash on embedded systems. It uses
uclibc instead of gcc since the latter is a huge beast. It
would be worth exploring exactly what and how this 
buildroot does what it does to better approach this 
problem. It might even be worthwhile actually using the
uclibc since you're talking ramdisk, you don't have 
anywhere near the constraints of embedded, in most 
cases there the entire root fs is within 4MB of flash.
How hard that might be depends on how much of 
glibc the speech dispatcher and such used. 

http://buildroot.uclibc.org/

Note the links on the page also to related sites. 
Busybox is one executable that provides trimmer 
versions of many of the linux tools. You'll find that
on most ramdisks, and there are trimmed c libs
(uclibc) and dhcp (udhcp) etc.

  -- Doug