Speakup does use modules, and it can be statically compiled into kernel instead. That's not a problem. The serial ports, however only support real serial ports, not usb-serial, which is becoming a problem. As I said a few months ago, the whole usb mess can be statically compiled, including the usb core, the host controller, and even usb-serial devices audio devices, and synth drivers, like the dtlk for example, so in theory it should be possible to boot and get speech output, with changes to speakup. As it is now, the code refers to the standard serial port addresses and irqs, and the communication code is RS232 specific. So this what I mean about abstraction. An abstract interface does not implement anything, it only defines. The implementation can be anything as long as it follows the interface. So basically there needs to be a layer of code in between the serial port code and the code that writes to it, one interface with several implementations, RS232 serial, USB serial, and potential for any other kind of implementation. And my argument was that the same could be done on the user side, pressing a certain key does some thing, currently assumed to be standard keyboard, but would be nice if abstract interface where the keyboard is one type of controller, other devices could trigger same. I'm mostly thinking about mobile pervasive systems, where you might want to read a message or email, not type, and your device is in your pocket. So you have a little controller sort of like a game pad where you can move between messages and read them etc, or get phone numbers from a list. If the interface to the synth is generic then there are all kinds of possibilities. I will be working on this kind of thing with speech, and I am still contemplating whether or not it needs to be kernel space. On an embedded device you really don't need to see all the boot messages, because it will load kernel from flash and will always work. If I find a way to adapt this code to work on arm then I might use it, but I actually think I could do the same thing entirely in user space. Boot is much simpler than PC and very fixed in nature, ie once done it shouldn't change, no need to support gazillions of types of hardware etc. I like the idea of being able to hear the console output, but then I might end up just using usb-serial console and having a microcontroller providing a terminal function, in other words both the speech and keyboard functions. If done that way it would possibly miss a very small amount of boot messages, but not many. It would be the same as using a terminal program with your PC connected to another PC with usb serial dongle and watching the other machine boot. -- Doug
