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."
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
Intriguing. I bet this could be useful for making a nice active firewall, instead of using iptables or a kernel module for the netfilter hooks. It should be interesting to see what ideas come of this.
The ocean parts and the meteors come down
Laid out in amber, baby.
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?
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.