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
