Slashdot Mirror
Schemix - A Scheme In The Linux Kernel
Phs2501 writes "Schemix is a Scheme running in the Linux kernel. It presents /dev/schemix to send Scheme forms to, and has extensions to read and set (C) kernel variables, call kernel functions, and make devices. If you've wanted to prototype your drivers in a high-level language that's 100% in the kernel, here you go."
Schemix
/dev/schemix which presents a REPL (Read, Eval, Print Loop) to anyone having access to the device.
/dev/schemix. Any output is written to /dev/schemix.
/dev/schemix
/dev/schemix /dev/schemix /dev/schemix
/dev/schemix /dev/foo /dev/foo /dev/foo /dev/foo /dev/schemix /dev/schemix /dev/foo /dev/foo /dev/foo: No such file or directory /dev/schemix /dev/schemix /dev/schemix /dev/schemix /dev/schemix /dev/schemix /dev/schemix
/dev/schemix REPL by doing 'echo "(exit)" > /dev/schemix'. Also, if you don't use any of the kernel-* functions provided by Schemix and just stick to R5RS Scheme, you should never be able to crash the kernel.
Schemix is a Scheme system, implemented as a patch to the Linux kernel. It aims to attain R5RS compliance while remaining small, fast and easy to understand.
The intended use of Schemix is for exploration of the Linux kernel and for rapid, interactive prototyping of Linux drivers and other new kernel features. To achieve this, Schemix will attempt to make a large subset of the kernel functionality available to Scheme programs. Interactivity is via a character device,
Schemix is based on a stripped-down and modified version of TinyScheme. Currently the system can be successfully compiled into a 2.4.x kernel, which then reads and executes Scheme code from
The following is a short example of a Schemix session (colour coded to make it easier to read):
$ cat
$ echo "(display (+ 1 2 3))" >
$ cat
6
$ cat >
(define foo (kernel-lambda (char*) printk))
(foo "Blah, blah, blah")
$ dmesg | tail -n 1
Blah, blah, blah
$ echo "(make-device foo ((a 1) (b 2)))" >
$ ls -l
crw------- 1 root root 10, 1 Mar 31 14:09
$ echo "(display a)" >
$ cat
1
$ echo "(display a)" >
$ cat
Error: eval: unbound variable: a
$ echo "(exit)" >
$ ls -l
ls:
$ # the following assumes there is an exported variable 'int blah' in the kernel source.
$ echo "(define read-blah (kernel-getter (int) blah))" >
$ echo "(define write-blah (kernel-setter (int) blah))" >
$ echo "(display (read-blah))" >
$ cat
0
$ echo "(write-blah 42)" >
$ echo "(display (read-blah))" >
$ cat
42
The most frequently asked question about Schemix is 'why?'. This is good. People should always ask 'why?' when something gets pushed from user-space into kernel-space. There are things about the Scheme language though, that make it a Good Thing to have in the kernel:
* Scheme is a very safe language. It doesn't allow you to create arbitrary pointers or over-run buffers. If you divide by zero, the universe will not end. This makes it a good language for prototyping, because prototyping is basically the act of making lots of mistakes until, eventually, you make the right mistake and call it a finished product.
* Schemix is small. It adds very little overhead to a kernel but provides lots of power and flexibility.
* Schemix can be very secure. If you are brave enough to use Schemix in a production system you can shut down the
* It's fun
The current release of Schemix (2.4.20) can be downloaded from here
Features that are planned but not yet implemented:
* The special forms kernel-getter and kernel-setter will be extended to allow getting and setting of multi-dimensional variables, e.g.
o (kernel-getter (char* 1024) foo) ; foo is a string with maximum length 1024
o (kernel-setter (int** 50 50) bar) ; bar is a two-dimensional array of ints (50 x 5
Long have C people rallied behing it for all uses simply because it can (and usually should) be used for writing drivers or kernels, even when the application in question is a desktop GUI app.
No longer does that argument apply- Schemix could be a great tool for those without a prejudice against Lispish languages who want to develop drivers or learn about the kernel. The value of an interactive environment cannot be understaed in the realm of learning, debugging, and development. I imagine this could be especially useful with kernel development, where debugging can be a bit harder than the usual user-space app.
Naturally, for most drivers, you'll end up converting or compiling the code to C from Scheme, but I imagine there are some situations where straight-up Scheme would perform fine. From what I can tell, Schemix itself doesn't include an implementation of a Scheme->C compiler, but I bet some wrappers for one of the many Scheme compilers could be written to allow folks to write, develop and debug drivers/kmods in in Scheme, and when you're all ready to deploy, compile to C.
Let's hope this sort of thing is the future of development- the lucky of us out there have been doing this for desktop development with Smalltalk and Lisp systems for quite a while.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
/dev/schemix?! I use /dev/urandom for these sort of things!
Note to self: get smarter troll to guard door.
When will the python version be released or the perl version and don't forget ruby? This reminds me of Script-Fu for Gimp. Lots of people didn't want to work in Scheme so a number of other scripting languages were plugged in. Most didn't do very much but Gimp:Perl is now quite robust. I wonder if this will fire up a flame war over scripting languages for interfacing with the Linux kernel.
I expect that if this project ever takes off, what will happen is that someone will make it run Perl too. Then everyone will use that instead and duplicate 95% of the problems we already have. But then, I'm sure all the Perl advocates are complaining about how Schemix uses a language 95% of programmers have never used before.
I've contacted the mailing list, but on the off chance that someone on here knows the answer: How is /dev/schemix created? Moreover, what major/minor numbers are to be used?
It's not in the dox, nor is it on the site.
Thanks!
Then, some other people implement a shell and several command line utilities in Emacs Lisp (EShell).
Then some other people implement a Scheme system inside the Linux kernel.
Secret long-term goal: create a self-sufficient Emacs (codename Emax) that boots, thus obtaining the One True OS! :-)
Yes, and to counter the Emax movement, we'll have VIMIX!
Thus the inevitable debate continues...
..I know you guys think the developer section is secure, just wanted you to know you got at least one non coder lurker. I usually have NO IDEA whatsoever is being talked about, but after around a year now (didn't register for a long time)at least some of the jargon is comprehensible. Not much, but some.
So this is a good idea, huh?
OK, lamer question. If you had never coded anything before, what language would you start with, and why?
its clean, freely available and good.
On the subject of schemes, be sure to check out the Scheme Shell . You may be particuluarly interested if you are looking for a cleaner way to write shell scripts.
Scsh has two main components: a process notation for running programs and setting up pipelines and redirections, and a complete syscall library for low-level access to the operating system, i.e. to POSIX, the least common denominator of more or less all Unices, plus widely supported extensions such as symbolic links and BSD sockets. Moreover, scsh provides an awk facility for pattern-directed computation over streams of records, a rich facility for matching regular-expression patterns in strings, event-based interrupt handling, user-level threads, a futuristic module system, and an interactive environment. Scsh comes with extensive documentation describing these and other features.
This would be a very interesting thing to use in conjunction with the Real Time Linux extensions, so one could dynamically modify their real time tasks. It would probably make the writing of the real time tasks even simpler.
--jeff++
ipv6 is my vpn
Sounds ... useful.. Scheme is such a nice language. Particular useful in the kernel I can imagine. ...er wait a minute!
The How to Design Programs book and DrScheme environment make for a good start. DrScheme has settable "language levels" that turn off advanced features. This lets you get more intelligible error messages when you're just starting out. Without this feature, programmer newbies get strange error messages when a typo unintentionally invokes advanced language features.
Now with something like scheme, if it could perform well enough and get robust and polished enough (I looked at schemix, it's still very primitive, no way you'll see it in Alan or Linus's kernel any time soon) but if it matures I could almost see that being used for some scheduling and some other tasks where you want sophisticated logic that it's complex to do in C and not always safe. Of course, that's assuming that some folks in the kernel would ever acutally agree to it.
C does not necessarily mean the driver is non-portable. One would only need to create a portable API.
Because drivers published by device manufacturers contain proprietary trade secrets, one would need to create a portable ABI (application binary interface), which has had even worse performance problems than a portable API.
Will I retire or break 10K?
people who wanted other languages in gimp, and did write their own
There is a difference between kernel space and user space. Perl is OK in user space, but I find Scheme in the kernel less objectionable than Perl in the kernel because Scheme is so much smaller than Perl.
Will I retire or break 10K?
Indeed.
I thought you were going to go on and suggest that a late-compile language like Scheme would overcome Linus's objection to microkernels.
Idea being that glue code necessary for modularization disappears as a result of run-time optimization, as in Java.