If your adaptive software lives in a user process, and you believe it belongs there indefinitely, you can skip this message. However, some people, myself included, want to put it in the kernel. There are many advantages to this strategy, and a few disadvantages. I hope that the use of loadable modules will remove most of the disadvantages. 1. I have recently added several new features to my speech package, and that makes the kernel bigger. What happens when I incorporate yet more features, or a software synthesizer? There is a hard limit on the size of the compiled kernel -- don't ask me why -- there just is. The only way out is to use loadable modules. The compiled kernel remains small, and if the blinux modules is a megabyte (including wave tables for an on-board software synth), so what? RAM is dirt cheap these days. 2. If the bulk of a speech package is sequestered in a module, it should be possible to hack the kernel once, and only once. The modified kernel sends keyboard and console data to the blinux module, which does whatever it does. I believe this reusable, one-time only hack would be accepted by Linus, and the development community. In contrast, nobody would add my package, or somebody else's package, into a standard distribution, because each package is too individual. But a blinux hook, and a collection of modules, just like sound card modules or file system modules, now that's the right approach. 3. Mid and high level managers sometimes express angst when you tell them you want to put a modified kernel into their system, or even on their intranet. They are worried about reliability and security, but they don't have a lot of technical knowledge. We have to pay atention to this group, because they are our employers. Now for the irony. They don't want us to mess with the kernel directly, but they don't mind if the extra code sneaks in through a module. Their customized system already loads lots of third party modules, such as ethernet drivers and sound cards, and that's ok. They're use to that. So, if blinux software came in as a module, they wouldn't mind so much. I know, it's totally irrational, but that's the way it is. 4. The blinux module is different from sound cards and file systems. If the module isn't present, or can't be loaded, the show must go on. The kernel hack, wherever and however it is implemented, cannot simply belly up and die if the module isn't there. (That's what happens with all other modules.) Instead, keyboard input must be routed to the OS, and tty output to /dev/console, as though there had never been a hack. We need a kernel that uses a module if possible, but runs a reasonable default behavior if the module is missing. 5. Once loaded, is the module ever really inactive? As a point of precedent, a file system module is active as long as a partition of that type is mounted. Yet /dev/console is always open, hence blinux is always active. This brings up the question of how we would rmmod and insmod it on the fly, a capability that I really want. I'm tired of installing a new kernel, running lilo, and rebooting, every time I want to test a new feature or bug fix. This gets old real fast. A modular design would fix this, only if we can rmmod and insmod on the fly. I would try to write the module so that it is only "in use" when it was actually running a speech command, or managing stream I/O. That little in-use bit will be toggling constantly, and I'll have to be careful about race conditions etc, but I think it will work. You type "rmmod blinux", and immediately after return, there is no speech, no keyboard input, and no tty output. The module is not in use, and can be removed. With no module installed, the kernel goes back to default behavior. You can then type, without feedback, "insmod my-test-blinux", and you're back in business. If youre test modules is a disaster, remove it and reinstall the working module. If your test works, move it to /lib/modules/version/char/blinux.o, and it becomes the official module for your system. 6. This is an unusually dynamic module, and it introduces another problem. The kmod utility automatically deinstalls modules that are not in use. No input/output activity for a minute, and kmod might just yank your blinux module. Needless to say, this is not what we want. However, if a module is installed manually, via /sbin/insmod, rather than via the kmod daemon, I believe it is left alone. Can somebody out there confirm this? If so, I can simply use insmod or modprobe directly to load it, and it should stay loaded thereafter. I should also make sure that the kmod daemon is never triggered for this module, hence it does not reload it after you unload it and try to use the console. I think all this is doable. 7. If the appropriate modprobe command is the first line in /etc/rc.d/rc.sysinit, we will miss only one line of output, and a rather inconsequential one at that. All earlier lines can be retrieved via dmesg, and all subsequent lines will be captured, because the blinux module is running. 8. The blinux parameters, such as the type of synthesizer, the serial port, irq or polling, baud rate, and other aspects of its behavior, become module parameters, stored in /etc/conf.modules. This is easier than boot-time parameters, which live in /etc/lilo.conf, and require a reboot to take effect. To change one of the blinux parameters, under a modular design, edit /etc/conf.modules, change the option, rmmod blinux, and insmod blinux. That's it. 9. I'm not sure how to approach the question of the synthesizer. We could leave it completely open and unconstrained for now. That is, each blinux module does whatever it does with synths. Or, we could establish another modular interface between the blinux module and synth module. This would determine how adaptive software uses a synthesizer -- any synthesizer. This sounds compellin, but there might be some tight coupling between the adaptive software and the synthesizer that would be dificult to realize if they had a rigid interface standing between them. This is especially true for software synthesizers. I'll have to think about this one for a while. I know some people are trying to establish a standard interface to all synths, and I do think that's the right way to go -- it's just another big piece to tackle. Maybe I should just work on the blinux module first, and get that interface established and implemented. One thing at a time. 10. It is important to get the modular interface right, or the "one size fits all" kernel hack won't really meet everybody's needs. Sometime next week I will try to write an RFC on this subject. Exactly what functions, with what parameters, will carry keyboard/console data to the blinux module, and what other kernel functions can this module invoke to do its work? Any thoughts would be appreciated. Take care, Karl