[quoted lines by Karl Dahlke on April 18, 2000, at 03:25]
>There is a hard limit on the size of the compiled kernel -- don't ask me why --
>there just is.
It has to do with the fact that the kernel loader has to be put somewhere, so
it is. It's put quite high up, but, since Linux is designed to run on fairly
small machines, it can't be put too high. If the kernel gets too big,
therefore, it overwirtes its loader.
>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.
Agreed. May I suggest that you put in the same hooks that SpeakUp uses. It's
probably got it right, albeit not modular, already.
>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.
They're not all that irrational. They also don't want to get into the
exponential thing, i.e. we need a zillion different kernels, one for each set
of combinations that someone might want. They see the logic and ease of mixing
and matching modules over building multiple kernel versions.
>We need a kernel that uses a module if possible, but runs a reasonable
>default behavior if the module is missing.
That's not the right way to express it. The kernel must behave exactly as it
does now, i.e. it must exhibit the default, rather than merely a reasonable
default, behaviour when the module isn't installed.
>
>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.
Don't tie the state of the module to that of /dev/console. The module need not
be open at all. Just make sure that its cleanup procedure, which will get
called during unloading, does all that is necessary before returning so that
the module uninstalls cleanly. This way, the module can be unloaded at any
time.
>6. This is an unusually dynamic module, and it introduces
>another problem. The kmod utility automatically deinstalls
>modules that are not in use.
Only if the -k option (see insmod) is specified, or if the code which supports
the hook itself either forces the -k option or checks for inactivity and does
its own unloading. You can tell if a module is subject to auto-unloading by
checking the output of lsmod. Such modules are marked as (autoclean).
>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?
As stated above, it all depends on whether or not -k has been specified either
as an insmod option or on the options line in /etc/conf.modules. kmod, by the
way, just uses modprobe.
>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.
Your code should use procedure variables. If a procedure variable is not NULL,
then call it, else do the default thing. The module's init procedure should
assign the procedure variables, and its cleanup procedure should NULL them out.
>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.
They can also be retrieved from the /dev/vcs image and/or the console buffer.
>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.
Another general hack might be worth while here, i.e. a new boot parameter to
list a set of modules which should be preloaded, and a convention to get
parameters passed to them. Here is an example to illustrate:
preload=mod1,mod2 mod1-opt1=val1 mod1-opt2=val2 mod2-opt1=val3
An approach like this would allow the brave to get it going right from boot
time. It might also be an approach to enable SpeakUp to become modular.
>9. I'm not sure how to approach the question of the synthesizer.
>We could leave it completely open and unconstrained for now.
You want a standard interface, and a separate module per synthesizer. You also
want to load the synthesizer under a generic name, and map it via an alias
directive in /etc/conf.modules.
May I suggest that you look at EmacSpeak for a model for the standard interface
as it has surely stood the test of time. It would also enable EmacSpeak to use
this facility, thereby centralizing synthesizer support.
>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.
Just support a superset functionality, and return "unsupported operation" for
things that don't work on any given synthesizer.
--
Dave Mielke | 856 Grenon Avenue | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me
EMail: dave@xxxxxxxxx | Canada K2B 6G3 | if you're concerned about Hell.