Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Schemix - A Scheme In The Linux Kernel 58

Posted by timothy from the sneaky-sneaky dept.
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."
This discussion has been archived. No new comments can be posted.

Schemix - A Scheme In The Linux Kernel More

Schemix - A Scheme In The Linux Kernel

Comments Filter:

  • Woot! Drivers in Scheme! (Score:5, Interesting)

    by RevAaron ( 125240 ) <revaaron@hotmail. c o m> on Sunday April 27, 2003 @01:59PM (#5820256) Homepage
    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.

    • Re:Woot! Drivers in Scheme! (Score:4, Interesting)

      by cpeterso ( 19082 ) on Sunday April 27, 2003 @06:02PM (#5821411) Homepage

      If device drivers were written in Scheme, then the same device driver could (possibly) work on an other OS that supported the Schemix driver API. You could have one device driver that works on Linux, Windows, BSD, ...

      • A side effect I didn't even think of! However, a Schemix driver for linux would have to be adapted quite a bit, unless there was a unified driver API. I've never done any driver programming, so I'm not sure how different the driver APIs are in Mac OS X, Linux, BSD, Windows, or other Unices. But as with all things, it could be a great thing to have!
      • C does not necessarily mean the driver is non-portable. One would only need to create a portable API. In fact, this has been suggested, but always rejected due to performance reasons.

        • 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.

      • however, there's a problem... how will people be able to write proprietary binary drivers ???
    • I can see a couple of problems with that.
      First, Scheme requires GC. Kernel memory isn't GC'd.
      Second, compilers from Scheme to C produce unreadable code (Hobbit is an exception, but it was buggy beyond repair last time I looked). Thus you would need to teach Linus Scheme to get that code into the kernel.
      Debugging and prototyping -- yes, but read Scheme code in the kernel -- no.
      • Linux wouldn't have to know Scheme for me to write various kernel mods or drivers available for download from my site. It doesn't have to be included with the kernel...

      • "First, Scheme requires GC. Kernel memory isn't GC'd."

        Well, the obvious thing to do would be to write non-consing Scheme code (possibly by restricting yourself to a subset of Scheme - see the reference to "pre-scheme" in this article [paulgraham.com] on the history of the T Scheme compiler). The other thing would be to write a garbage collector for kernel memory (or at least those parts that Schemix uses - again, see the abovementioned article on T for a mention on how they built a GC for T in T). I think the former is do

    • "Long have C people rallied behing it for all uses simply because it can (and usually should) be used for writing drivers or kernels"

      "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."

      I find this attitude that C is the only language with which to do systems programming really surprising. No one seems to reme

  • /dev/schemix?! I use /dev/urandom for these sort of things!

  • But I wanted... (Score:5, Interesting)

    by cornice ( 9801 ) on Sunday April 27, 2003 @02:55PM (#5820489)
    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.

    • Re:But I wanted... (Score:5, Interesting)

      by RevAaron ( 125240 ) <revaaron@hotmail. c o m> on Sunday April 27, 2003 @03:15PM (#5820560) Homepage
      I doubt this will fire up any flame war because:

      a) not many people are registered to get this story, only people who specifically have an interest in the Developer section. It doesn't show up on the regular front page. Most of the idiots who would flame are weeded out that way.

      b) Anyone who thinks that the Schemix team should've implemented Perl, Ruby or Python kernel hooks should just quit crying and do the work themselves. There's a good chance that they'd find that in the course of the work that Perl/Ruby/Python would be more work to port into the kernel and use a huge amount of RAM, compared to TinyScheme, upon which Schemix is based. TinyScheme truly is tiny- less than 100k for the entire binary installation including a fair amount of library.

      • Re:But I wanted... (Score:3, Insightful)

        by JohnFluxx ( 413620 )
        What's with the negative attitude, dude?

        "Anyone who thinks that the Schemix team should've implemented Perl, Ruby or Python kernel hooks should just quit crying and do the work themselves"

        I haven't seen anyone complaining. And the parent gave a perfect example of people who wanted other languages in gimp, and did write their own instead of "crying".

        • It's not a negative attitude, so don't worry. Read the parent to which I replied. :) He said: I wonder if this will fire up a flame war over scripting languages for interfacing with the Linux kernel. My reply was to a question of his.

          I haven't seen anyone complaining. And the parent gave a perfect example of people who wanted other languages in gimp, and did write their own instead of "crying".

          Indeed, no one is complaining. And that's good. I didn't say anyone is. However, in the event someone di
        • I think it was a pre-emptive attack.

        • 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.

      • Actually this story is on the front page, so flame on! :)

        A very interesting development indeed, and I think that if anyone were to do work on a Perl/Ruby/Python kernel-plugin I think they'd probably start with a scheme interpreter. These interpreters tend to be good starting points for more complex languages.
        • Or, one could use the existing Schemix system as-is, and write some code in Perubthon (heh) to wrap the API and generate scheme code. After all, it is just interfacing with /dev/schemix - you wouldn't even have to mess with sockets or some other RPC format.
    • scheme/lisp are easy to parse because valid input is already in a () list, and includes recursively embedded lists. That makes building the parse trees trivial (instead of the interpreters doing it, the user does it).

      gimp/script-fu used SIAD - Scheme In A Day -- a scheme interpreter (allegedly) written in 1 day. Could anyone write a perl or python interpreter in one day?

      Of course, most of the scrupt-fu scripts where more iterative than recursive. A procedural language like perl is better suited for t

  • I was just thinking of something like this while taking a shower this morning. I was thinking more of a world where all the standard Unix programs were written in an interpreted language (and Scheme was my choice since I like it). I guess I thought of this as a result of that Unix-haters book. We really do have powerful enough computers nowadays that we shouldn't be using the speed of C to justify its use, and interpreted languages allow us to avoid some of the most dangerous types of bugs. Perhaps more

    • Re:Good timing! (Score:5, Funny)

      by Ed Avis ( 5917 ) <ed@membled.com> on Sunday April 27, 2003 @03:53PM (#5820717) Homepage
      Now all we need is for RMS to reimplement Emacs in Scheme, then we can put Emacs in the kernel, and then finally the UNIX-HATERS people might be happy!

      • Re:Good timing! (Score:3, Informative)

        by aminorex ( 141494 )
        ...reimplement Emacs in Scheme...

        Been done: Edwin.

        It came with TI PC-Scheme in the mid-80s.
        Google it, you might find a copy in the wild.
    • "I was just thinking of something like this while taking a shower this morning."

      If you're going to lie, you should do so less obviously :P

      Just kidding..

    • We really do have powerful enough computers nowadays that we shouldn't be using the speed of C to justify its use


      God knows computers are way too fast already. . . I'm sure no one would notice if real-time hardware was run in an interpreter.

    • "Perhaps more importantly, true high-level languages let us achieve a much higher degree of portability, at least in theory. And interpreted languages let us do all sorts of nifty things (like closures) for when you really need the power."

      You should really stick to calling them "high-level" instead of "interpreted" languages. There's certainly no reason lexical closures can't be compiled (personally, I use CMUCL, so I get the benefit of an optimizing native-code compiler, but bytecode compilers also aren'

      • 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.
    • FYI, lexical closure have nothing to do with the fact that Lisps can are interpreted. They could work identically in a compiled language, such as a compiler-based implementation of Lisp.

      Lexical closures work because of lexical scoping (and vice-versa depending on how you approach it).

      To drive this point home, there are plenty of interpreted languages that don't have lexical closures. For example, python.

      Justin Dubs

  • 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!

  • Evil plot revealed: (Score:5, Funny)

    by ianezz ( 31449 ) on Sunday April 27, 2003 @04:24PM (#5820868) Homepage
    First, people make an Emacs clone for MIT Scheme (Edwin [caltech.edu]).

    Then, some other people implement a shell and several command line utilities in Emacs Lisp (EShell [emacswiki.org]).

    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! :-)

  • ..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?
    • Depends, I my self love to code in any language i've ever seen. So if it was me.. i dunno I might do LISP or Scheme to start because they are extremely powerful and knowing one of them well, could be a very beneficial thing. On the other hand since most of coding is not done in functinoal languages I might start with C. C is the most beautiful language I think. almost as low as machine language yet a high level language that is extremely powerful, I gotta love it. So i dunno, I'd say if you want to bec

    • OK, lamer question. If you had never coded anything before, what language would you start with, and why?

      That depends on the reasons behind your interest in programming.

      Wan't to quickly create a Windows app? Visual Basic (the language is ugly, though - it didn't even have array constants last time I checked) or Delphi (Object Pascal isn't perfect either, but still much better).

      If you just want to learn basic programming techniques, I agree with previous poster that Python is very friendly and yet elega

    • The How to Design Programs [htdp.org] book and DrScheme [drscheme.org] 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.

    • For ease of use and teaching you good principles, Python would be ideal. On the other hand, if you are thinking of making this a career, you might want to consider Java. It is also relatively straightforward, although a bit less "high-level" than Python, and it has very widespread acceptance in the commercial world.

      dave
    • Lamer answer: Depends what you want to do.

      I've studied about ten[1] and learnt something from each of them. ...but only Java and C++ rock.

      Justin.
      [1] Thinks... several Basics, C, C++, Pascal, Fortran (shudder), Lisp, Java, JavaScript, Oracle PL/SQL, Rexx. There's prolly more...
  • 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++
  • Sounds ... useful.. Scheme is such a nice language. Particular useful in the kernel I can imagine. ...er wait a minute!
  • Several people on the kernel list have always been against this stuff. I remember seeing some messages by a few people working on implementing Forth in kernel space. Sun uses forth for their firmware, it is a great step above assembly language that is tiny and easy to implement. I'm not sure how practical it is to expect scheme drivers but forth drivers are very realistic. http://www.dedasys.com/freesoftware/files/kpforth - 21.tgz>here is one link [slashdot.org]. I'm not sure if it's a good idea or not, there i

Slashdot Top Deals

You know you've landed gear-up when it takes full power to taxi.

Close