Doug your talking a lot of sense, and when I mentioned about speakup and how it accesses serial ports I think I was thinking back to some of your comments. You have within this thread mentioned should be speakup be a combination of kernel code and user space code, I think I may have mentioned this before and would also support this type of idea. As an example, I think the jupiter speech system is this combination approach, how does it compare to speakup for ease of being maintained to work with newer kernels, I know that there has been some times in the past when speakup has had to be altered specifically for newer kernels (sometimes breaking it for the older kernels). Another thought about this idea of making the core of speakup not be interface specific (which I think would be a good idea), is that I think on the list someone asked about a headless install, and there was a reply that if by headless this would also mean no video card, then speakup wouldn't work, I don't know if it could be done another way, but this seems a bit specific (thinking, may be speakup would have a driver to access video memory, but also could have another dummy graphics driver should the machine not have a video card). Having all the boot messages, while it is useful, and speakup is about the only way I know how to get the messages at the time (all, from the earliest possible moment), the question should be asked, on a properly configured system, how many problems might realistically occur before such a stage as USB console can work, and eventually the serial ports that speakup can currently use will soon be gone if the trend of hardware manufacturers is anything to go by. I don't know how many are actually working on speakup, but I think it is only a few and speakup is probably not the only thing for them. I have to admit as I understand things we are going to have to make hard decissions and put what effort in the best direction, may it need to be a complete rewrite, etc. From Michael Whapples On Mon, 2007-06-18 at 01:18 -0500, Doug Sutherland wrote: > 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
