forth interpreter as kernel module
[ please CC replies to me ]
Hello,
Once upon a time, I had a rather random idea, and, acting on it, I wedged a forth interpreter into the Linux kernel. I've always wanted to clean it up and do things nicely, but have never really found the time or the motivation.
So, I am posting here, in the hope that someone might find the idea interesting and take it up, or, better yet, think of something that it might actually be used for (this was besides the point when I did it).
I doubt the code itself is of much interest. Actually, I'm pretty embarassed about it, but decided to make it available despite that.
It does run, on my system (2.4.18):
@grantspass [/home/davidw/workshop/pforth-21] # insmod kpforth.o
Warning: loading kpforth.o will taint the kernel: no license
@grantspass [/proc] # echo 3 . > kpforth
@grantspass [/proc] # cat kpforth-out pfLoadDictionary - Filename ignored! Loading from static data. Static data copied to newly allocated dictionaries. Begin AUTO.INIT ------
3 ok
Stack<10>
Although from what I recall when experimenting with it, there are some definite 'issues'. See aforementioned disclaimer about the code. It doesn't interface with the kernel in any interesting ways, either.
Anyway, for the interested/bored/adventerous, the code may be found at:
http://www.dedasys.com/freesoftware/files/kpforth-21.tgz
The original forth system that I based it on - pforth - which is much better code then mine, is by Phil Burk.
I would be interested in comments on what should be fixed in the code, although I may not have time to act on them.
Anyway, hope this is of interest to someone, and thank you for your time,
Signature · 5 lines
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/Quoted 7 lines · David N. Welton
[ please CC replies to me ]
Once upon a time, I had a rather random idea, and, acting on it, I wedged a forth interpreter into the Linux kernel. I've always wanted to clean it up and do things nicely, but have never really found the time or the motivation.
We had another similar post a few weeks ago. *Two* Linux kernel Forth interpreters in one year -- what are the odds? :)
Seriously, though, a Forth that could be accessed inside the kernel has profound (in)security implications. I'm not sure I like the thought of something as powerful as Forth available with kernel privileges. It would make an interesting debugging / diagnostic tool if "kgdb", etc. didn't exist, but given that there *are* some debug tools already, I'm not sure what I'd do with it.
Now a *user-space* full-featured Forth -- something like Tom Zimmer's Windows32 Forth or Forth, Inc.'s SwiftForth -- with GUIs and all the other goodies -- now *that* I'd love to have. But a tiny Forth in the kernel? Nope.
Signature · 8 lines
M. Edward Borasky [email protected] The COUGAR Project http://www.borasky-research.com/Cougar.htm Q. How do you tell when a pineapple is ready to eat? A. It picks up its knife and fork.
Quoted 2 lines
I would be interested in comments on what should be fixed in the code, although I may not have time to act on them.
Strange. The one area forth does have sort of relevance may be outside the x86 world. The portable boot rom standards (the one everyone ignored for x86) is all about forth stuff. I don't know if anyone has use for a forth engine that can speak that ?
Quoted 7 lines · Alan Cox
Quoted 2 lines
I would be interested in comments on what should be fixed in the code, although I may not have time to act on them.
Strange. The one area forth does have sort of relevance may be outside the x86 world. The portable boot rom standards (the one everyone ignored for x86) is all about forth stuff. I don't know if anyone has use for a forth engine that can speak that ?
The openbios guys are working on it. I haven't played with it but they seem to be makeing some progress.
Eric
Quoted 7 lines
Quoted 2 lines
I would be interested in comments on what should be fixed in the code, although I may not have time to act on them.
Strange. The one area forth does have sort of relevance may be outside the x86 world. The portable boot rom standards (the one everyone ignored for x86) is all about forth stuff. I don't know if anyone has use for a forth engine that can speak that ?
Yes, an OpenFirmware emulator would be interesting. It would allow to softboot OF PCI cards on non-OF machines, and would allow to implement properly resume from sleep on some desktop G4s that will power off the PCI bus during sleep (some cards need to be re-softbooted, like video ones, and in some case, you really want the vendor firmware to run).
Ben.
Quoted 5 lines · [email protected] wrote:
Yes, an OpenFirmware emulator would be interesting. It would allow to softboot OF PCI cards on non-OF machines, and would allow to implement properly resume from sleep on some desktop G4s that will power off the PCI bus during sleep (some cards need to be re-softbooted, like video ones, and in some case, you really want the vendor firmware to run).
I'm writing a full OF implementation for OpenBios. It will also be able to run in user space, which might be a better solution for things like softboot (and besides, it makes development a lot easier).
It is supposed to be fully portable across all architectures that run Linux.
Check out module Paflof from OpenBios CVS.
http://www.freiburg.linux.de/OpenBIOS/
Nothing very mature yet, so don't get too excited now.
Cheers,
Segher