share
Stack OverflowWhy not port Linux kernel to Common Lisp?
[+81] [17] rplevy
[2009-12-04 16:18:49]
[ c linux lisp linux-kernel common-lisp ]
[ http://stackoverflow.com/questions/1848029/why-not-port-linux-kernel-to-common-lisp ] [DELETED]

Conventional wisdom states that OS kernels must be written in C in order to achieve the necessary levels of performance. This has been the justification for not using more expressive high level languages.

However, for a few years now implementations of Common Lisp such as SBCL have proven to be just as performant as C. What then are the arguments against redoing the kernel in a powerfully expressive language, namely Common Lisp?

I don't think anyone (at least anyone who knows what they are talking about) could argue against the fact that the benefits in transparency and readability would be tremendous, not to mention all the things that can't be done in C that can be done in Lisp, but there may be implementation details that would make this a bad idea.

(5) It didn't look like a real question, but it is. The question should be open. - Ewan Todd
You should give a look at bitC and Coyotos OS if you're interested in such things: en.wikipedia.org/wiki/BitC - Stringer
(3) +1 for being a real question. -1 for 'performant'. The word you are looking for is 'efficient'. - Thanatos
(2) I think it's a legitimate question. And maybe it could be the case that we would be in a better position today if the kernel were in Lisp, but the effort to port it now would be prohibitively large. - Nick Lewis
(4) It's a real question, but things like "The gains in clarity and maintainability" are subjective and argumentative. - Powerlord
(159) I feel like this is asking why not move Mt. Everest to California. - Jay Conrod
(5) Just go ahead and do it. Many years down the road, you'll get it done, think to yourself "There, I did it! I knew it could be done. Now what?" and that will be the end of that project. That's an awful lot of work for a proof-of-concept. - Graeme Perrow
(8) No reason you can't do systems programming in Brainf*ck for that matter, so let's port the kernel that way too. It's Turing-complete, after all. - Mark Rushakoff
(7) @Mark Rushakoff: However, OSs have been written in Lisp, and it's far easier to use than BF. Common Lisp has a great many advantages over C, although I'm not sure how well that would work for kernel hacking. - David Thornley
(18) I could just imagine. O hell I have one parenthesis off in : ))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))) ))))))))))))))))))) - corymathews
(23) @corymathews: That's what the editor is for. I've written Lisp code in plain text editors and editors that supplied parenthesis matching and automatic indentation. I never want to do the former ever again. - David Thornley
(2) How, pray tell, does one load the GDT register in SBCL? - caf
(5) caf: Exactly the same way you do in GCC: with compiler-specific inline assembly. How did you think a self-hosted natively-compiled language implementation worked? - Ken
(1) A self-hosted natively-compiled language implemenation does not need to support inline assembly - witness the selfhosted Brainfuck-to-x86 compiler. SBCL does not appear to support such. - caf
(1) @caf in the sbcl source look at src/assembly, compiler-specific assembly, written in clean expressive Common Lisp code is what you see there. - rplevy
(7) And the best part that Linus does not know Lisp, two birds one stone. - Istvan
(1) If you want to port a kernel to Lisp, I would recommend starting with GNU Mach, as it's surely much smaller and you'll have a much better chance of success. - Nostradamnit
[+124] [2009-12-04 18:01:57] Rainer Joswig [ACCEPTED]

There are possible variants of this question. Let's first ask what is the 'Linux' kernel. Linux is basically some variation on Unix. The Linux kernel provides services as memory management, ...: alt text

The kernel parts and the interfaces all assume some C compiler and C language conventions are used. A C compiler can generate a compact executable.

Now things get difficult in Lisp. It shows in SBCL. Fixnums in SBCL are 61bit and not 64bit. Some bits in data are used for tags (and possibly other things). SBCL programs start at multi-megabyte size. Characters are not bytes, but again tagged data. Most Lisp implementations use tagged data, because the data needs to be identifyable at runtime - in Lisp.

C has very different data structures, etc from Lisp. If you write something in Lisp it would by default look very different from C code. Wouldn't a scheduler be best a CLOS object? Tasks? Timers? But the interfaces of the Linux kernel look very different. You would program very primitive data structures in a language that has higher-level data types (like CLOS). That's not a very good fit.

So, can you define a Lisp that is nearer to C in its capabilities? That's possible. There are some examples.

Also, can you write an OS that would not look like Linux, but is written in Lisp and is more idiomatic? That's also possible and has been done before.

The typical Unix (and Linux) OS 'kernel' does a few things that were not done in the typical (existing) Lisp OS: different applications with their own memory space, multi-user capabilities, ... that would be new ground for a Lisp-based OS and had to be invented first: how to provide multiple independent Lisp applications on top of a Lisp OS and not lose the advantages of a typical Lisp system.

Probably it would be better to not write an OS in C (for example one might want a language and implementation with real array bounds checking) - but the language better be near the C model - otherwise lots of knowhow is not transferrable. Lisp solutions usually look very different.

A real Lisp OS looks very different.


Great answer. Question, though(since you know what you're talking about here): would it be 'reasonably possible' to have a Linux-compatible interface, e.g., the syscalls & driver interface? The internals obviously will be quite different. - Paul Nathan
(6) Paul, it simply does not fit. You could pound a square peg into a round hole with lots of force. But the result would not be pretty. Huge amount of work, alone providing the interface would be a lot of work with lots of internal bit fiddling. - Rainer Joswig
(5) The problem with real array bounds checking is that it takes code and execution time at runtime. For most purposes, this is just fine, but there's stuff in the kernel that really needs to run as fast as possible, and so the correct approach is to set things up so the index will not be out of bounds and prove that that works. C is at least close to a sweet spot for kernel hacking: it's darn close to being a multi-CPU assembly language. - David Thornley
(11) We have to pay for the lack of bounds checking every day. People run slow stuff like Ruby on top of a fast unsecure kernel. A bad match. I don't even have the choice - all typical Unix OS variants are compiled without bounds checking. I would use that - even if it is a few percent slower. - Rainer Joswig
(6) Bounds checking alone will not save an OS or make it secure.. it only takes some of the load off the programmer. - Earlz
(2) That would be a start. - Rainer Joswig
(2) As I understand it, typical Lisp systems were circa 1978-1990. So a real modern Lisp OS will look different both from the historical lisp OS and from the Linux... - Paul Nathan
Could be. If you could find funding and people for that? Currently it is not even possible to get the existing stuff improved or copied. - Rainer Joswig
(1) @Rainer - You're completely wrong. Kernels need to be fast. If they took the time for bounds checking, they would be unbearably slow. Saying "performance doesn't matter" won't convince your customers who are waiting for their program to finish (or web page to load) because your kernel is more "secure" because of it's bounds checking. The frequency at which kernel code must be used, combined with the overhead of bounds checking, means that, in certain areas, we have to go with something that is either a) provably correct, or b) works as far as we (the users) can tell. - Chris Lutz
(43) Chris: @You are completely wrong. Not everyone needs the fastest kernel. There are tradeoffs. If your financial data server gets hacked, 'fast' has not helped. Last years our computers were half as fast. They worked, too. What have we used the speed increase for? Some wished it would have been used for a safer infrastructure. Instead it is wasted in slow scripting language driving the web sites. If speed really mattered, Ruby, Python, Abap, and all this stuff would not be there. - Rainer Joswig
Runtime bound checking is retarded. You need it only for code that is buggy in the first place. I manage a multi million LOC project in C and not once in the 8 years I worked for that project would a bound checking have helped to find a bug. Are there array bound overflows in our code? May be, probably not much. Would it matter, not in the least, would the wasted time matter, yes a lot. If bound checking matters to you, go on,play with Java, Pascal and others, but let us our C which allows us to get as near as bare metal as it gets. - tristopia
(23) @tristopia : the damages done by security leaks in C speak another language. Every day hackers find the most primitive bugs in widely used software written in C. It is already kind of a sport. Many of these problems come from buffer overflows. That's a fact. That you think your software doesn't have this problem doesn't matter. The problem reports for many popular C-based software shows the huge scale of the problem. People like you should be kept far away from any security relevant software. - Rainer Joswig
(4) People that write bad C should be kept far away from any security relevant software. LISP is not better than C. It is different. Some people prefer C, some prefer LISP. Get over it. - alternative
(1) Thanks for the picture! - Liran Orevi
(1) @ChrisLutz and Rainer: Neither of you are completely wrong, you're both partially right! Speed matters to the extent of being paramount in some cases, and where there can be (mathematical?) proofs of correctness, dropping checks can win big. Also, there are many cases where it's not so much as paramount, even if important, and so things like bounds checking are worthwhile. My main point, though, is could we skip the hyperbolic attributions of wrongness? Instead, let's look at what's right, and from which perspectives; different perspectives can change a right to a wrong, or vice versa! - lindes
1
[+57] [2009-12-04 16:23:30] Nick Lewis

But you see, someone's already written the Linux kernel in C. Around 11 million lines of C. Porting it to Lisp would be far too much work for far too little gain.


(8) I disagree, that the gains would be little. The gains in clarity and maintainability would be enormous (and I bet it would come down to a lot less than 11 million lines eventually), and the work would not be done by the same people who currently hack the Linux kernel, but by people who would otherwise not have been as interested in it. - rplevy
(40) The people who would be doing the port, and who are not interested in systems programming, are likely much less knowledgeable about systems than the people who currently hack the Linux kernel. Also, what is unclear about C? Even disregarding the massive effort to rewrite the code, it would be an even more colossal task to test all of that code again. - Nick Lewis
(2) rplevy is right; a rewrite in Lisp would almost certainly drop the LOC count due to the Lisp higher-level features. - Paul Nathan
(19) Sure, it would drop the LOC count. It would also limit the number of people interested in working on it (since there are far fewer Lisp hackers than C hackers), and drive away lots of people. - David Thornley
(9) I would say that you are not looking to "port" Linux to Lisp, but rather to write a kernel that would be compatible with Linux from the API point of view. Which may actually be possible, but still take years of effort and the kernel ABI isn't stable, so that'll be fun to try to keep up with each new version. - Earlz
2
[+40] [2009-12-04 17:02:13] Mr. Shiny and New 安宇

I strongly suspect you are a troll for using such inflamatory wording, but I'll answer nonetheless.

There are several things wrong with your premise:

  1. You claim SBCL is as performant as C. What does "as performant" mean? In the kernel world even a 1% or 2% performance regression is a major problem.
  2. Lisp's readability is one of those things that is highly trumpted in lisp circles and otherwise disbelieved. I have a Computer Engineering degree and studied Lisp and C in school and can honestly tell you that I find Lisp harder to use. I'm sure millions of programmers agree with me. C is not the best language ever but neither is Lisp.
  3. There is nothing that can't be done in C which can be done in Lisp. Some things may be easier to do in Lisp, but since you can write a Lisp engine in C then C can do anything Lisp can (and more).
  4. Garbage Collection: GC is great but not well suited to applications which require specific deterministic performance. The Kernel falls into this category.
  5. Rewriting code is hard and porting is harder. Changing code for the fun of it introduces bugs (this is a guarantee) and reduces features.
  6. C lets the developer tweak even the tiniest detail. This is critical when you need to do things like ensure that a data-structure fits in a cache entry for your target processor. How do you do that in Lisp? Is it even possible? These are details that kernel developers have to deal with all the time. Kernel developers are still counting bytes.

In short, porting the kernel to Lisp would bring: reduction in readibility, performance loss, reduction in available programming talent, fewer features, and more bugs. That's why nobody will do it.


(39) I'd say enthusiast, not troll. 1. This can be tested. 2. Millions of programmers have never given Lisp a fair shot. 3. There's nothing you can do in C that you can't do on a Turing machine simulator. This argument is a non-starter. 4. Lisp normally uses garbage collection, but can handle its own memory. 5. This is the good reason. 6. Since you don't know Lisp well, or SBCL in detail, you're hardly in a position to criticize it for missing features. - David Thornley
(13) @David Thornley: 1. It's not up to the Linux devs to prove that Lisp isn't as fast as C, it's up to the Lisp folks to prove that it IS as fast. 2. Maybe true, but not that relevant; the more obscure the language the harder to get programmers. That's pragmatism. 3. The question claimed that Lisp could do things C cannot. False. 4. Fine, but then isn't one of Lisp's advantages lost? 5. Glad we agree on one thing :) 6. I'd love to be educated on how to control the precise size of data structures in memory in Lisp. This is one thing I know the kernel devs actually do frequently. A link would do. - Mr. Shiny and New 安宇
(6) A typical Lisp system provides a Foreign Function Interface (FFI). It usually has constructs to define data types. Like this: common-lisp.net/project/cffi/manual/html_node/… In a Lisp OS there are similar constructs to define such types (to interface to hardware or network services). But other types defined by the OS for itself just uses Lisp objects (CLOS, Flavors, Structures, ...). - Rainer Joswig
(7) your points 4,5,6 are strong and reflect reality. however, I think you should overlook point 2 after you seriously program Lisp. After a few weeks of Lisp programming, you start to see code that looks visually similar to Python, and I think Python code is beautiful. I was positively surprised when I discovered that while writing Lisp, you get the same visual satisfaction that you get from writing Python. - Luka Ramishvili
and point 3: there are things that you can't do in C but can in Lisp (simplest example: pass function (not function pointer) as an argument, macros (it ain't anything like C macros), etc), but these are programmatic features that don't exist in C. of course, a final executable file (or image, or script file) in Lisp cannot do more distinct things than a final executable file can in C. they both can manipulate memory, communicate with devices and other computers, etc. but that wasn't what you meant anyway :) - Luka Ramishvili
@LukaRamishvili: Sure, Lisp provides some features out-of-the-box that C doesn't have, but if those features were necessary for the kernel then they'd be added. How does passing a function differ significantly from passing a function pointer, for example? - Mr. Shiny and New 安宇
(3) @Mr.ShinyandNew安宇 That features aren't needed by the kernel, they are needed by a programmer. C does fine in the OS market. Lisp is just a solution that should exist (like C did fine as a programming language but Lisp still ought to exist). I think, by now Lisp OS-es should be researched, not shipped (to allow refining them). - Luka Ramishvili
(2) using any functional language will tell you the difference: 1) function pointers cannot be used as closures. 2) you can pass "anonymous" functions (created in runtime) as arguments, but you can't do it with function pointers because without functions created in runtime, there are no pointers to them. and many others but I can't think of more now :) - Luka Ramishvili
@LukaRamishvili: Sure, closures are nice, and anonymous functions are nice, but neither is really essential and both can be emulated in C without too much fuss. Garbage collection (implied by closures) is a major issue for a kernel and so I'm not convinced that this bit of programmer convenience is worth the costs. - Mr. Shiny and New 安宇
(1) @Mr.ShinyandNew安宇 My point was to answer how functions as variables differ from function pointers, not that closures are great for kernel programming. If I had to implement an OS in Lisp, I would first implement the Lisp in which I would program, and then build the kernel around it. I wouldn't use existing mainstream lisps for that. And btw, lisp can be as efficient as C, if you break it down to low level operations. Though lisp is (and is claimed to be) a high-level language, its history shows how close it can be (and has been, too) to the metal (car and cdr names are an example). - Luka Ramishvili
(1) @LukaRamishvili: My point is that Lisp can't really do something that C can't, because anything you can do in Lisp you can do by emulation or libraries or directly or whatever in C. And when any particular Lisp feature gets promoted as an example of how a Lisp kernel would be so much better than a C kernel, it always turns out that the C kernel already does that lisp thing, or the lisp thing is too expensive. Lisp might be super nice and all, but in the end it doesn't offer enough advantage over C to outweigh its costs, especially for existing code that would need porting. - Mr. Shiny and New 安宇
(2) @Mr.ShinyandNew安宇 I'm not arguing here with you. What you say is true, but with minor implications: every programming language is turing-complete, so anything lisp does can be done in C, FORTRAN or machine code (without this, we wouldn't be able to compile lisp). Current models of lisp compilation do not offer any options to write an OS in them. - Luka Ramishvili
(1) @Mr.ShinyandNew安宇 Meanwhile, a lisp OS is wanted for a number of reasons (at least these are my reasons). First, UNIX-like architectures offer OS API in the C model of programming. A Lisp OS would offer API in the lisp model, which would be interesting. Proponents of this idea don't want to abandon UNIX in favor of a new OS - they (including me) want to see how this could be implemented and which advantages it may offer. - Luka Ramishvili
(1) @Mr.ShinyandNew安宇 So, performance is not an issue - we don't want to build commercial software with this project (nice, so that's already a project in my head:)), it's intended for research. As with many other lisp projects, it may start slow and powerful, and then grow fast (I guess I'm quoting PG here). It would be interesting in projects where the ability for Lisp to directly interact with the outside world is more important than performance (say, a robot to research perception), not for web-servers or for hosting desktop applications (though it may be made suitable for such purposes too). - Luka Ramishvili
@LukaRamishvili: If you want a new OS that's not Linux but is some kind of Lisp thing, that's fine. Go nuts. My points were in the context of porting Linux from C to Lisp. - Mr. Shiny and New 安宇
@Mr.ShinyandNew安宇 So basically we're both saying the same. Maybe I missed the point a little. Sure, porting Linux to Lisp and hoping that it will be usable would be just pathetic :) The Lisp OS could have an API similar to UNIX, so that all existing programmers will automatically be knowledgeable about the OS. but that's not the main thing. - Luka Ramishvili
@Mr.ShinyandNew安宇: Regarding the question of whether C can do everything Lisp can do, It seems as though you're thinking about it in a less-than-fully-helpful way. In case I'm right, I recommend reading about "The Blub Paradox", in (and perhaps reading all of) this article: paulgraham.com/avg.html - lindes
(1) @lindes In the 5th paragraph under the "Blub Paradox" heading the author outright states a whole list of exceptions to the "rule" that Lisp is the best language. Many of those exceptions are the same as, or congruent to the reasons I posted in my answer. There are many good reasons not to use Lisp for kernel programming. Where Lisp has a feature that is extremely useful, there are ways to accomplish that same feature in C. Sometimes it's harder than Lisp, or not as general a solution, but it's possible. And the reasons for keeping C remain very compelling. - Mr. Shiny and New 安宇
I'm not arguing against the point of C being better for kernel development, only against the idea that because "there are ways to accomplish that same feature" really means that "anything lisp does can be done in"....... from the pure machine-theory standpoint, yes, but what gets missed is certain ways of approaching certain problems... certain ways of thinking about things. I'm not arguing that you're wrong, just that there are other ways to think about it that are, perhaps, worthwhile. Though maybe not in this context. ;) Anyway... just a thought. - lindes
3
[+32] [2009-12-04 16:55:35] Svante

There are projects that aim to implement "Lisp on the bare metal", e.g. Movitz [1] (there were also the famous Lisp machines [2]). Having Lisp in such a central role would also mean significant changes to how the system is designed, e.g. having a garbage collecting memory system, different library interaction etc..

So, you wouldn't port any OS to Lisp, you would write a new Lisp OS. I would be very excited if that becomes usable.

[1] http://common-lisp.net/project/movitz/
[2] http://en.wikipedia.org/wiki/Lisp%5Fmachine

(4) The Lisp machines failed largely because it was impossible to keep up with Intel and Motorola CPUs in performance. Running MCL on the Mac or Franz Lisp on Windows gave better performance and was cheaper (even for Franz). Implementing on the bare metal is probably impractical. - David Thornley
(10) The problem was not the performance (that could have been fixed and was about to be fixed), but the cost. The question was not about the hardware, but the OS. The OS has been ported to emulators and today runs on non-Lisp hardware. The OS has not been ported to a native machine - that would be possible - but there is no funding for that, and the interesting sources are not 'open source'. - Rainer Joswig
Thank you for the reference to Movitz! That sounds interesting. - Arne Babenhauserheide
4
[+15] [2009-12-04 16:24:07] moonshadow

It is a complex piece of code that already exists. Change is risk, so generally requires a good reason in order to happen.

Is there a good enough reason here to scrap and rewrite what there is? What do you hope to gain by doing so that would begin to be worth the cost of rewriting and testing and the risk of replacing a mature codebase with a completely new one?

No-one's stopping you, mind ;)


I think he didn't mean to change/rewrite linux in Lisp, he meant to implement a Lisp OS similar to linux (UNIX architechture). That doesn't mean replacing existing codebase. Though what you say about the cost is still true. - Luka Ramishvili
(1) Some thoughts on reinventing wheels: codinghorror.com/blog/2009/02/… - lindes
5
[+14] [2010-01-05 00:35:09] Chad

Because Linux is open source, and no one wants to read source code when the last page of it is:

)))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))

I kid, I kid.


(1) Hahaha, you earned my +1 for that. Thank goodness emacs was around in my undergraduate days. - ChrisInEdmonton
(23) I don't find spreading stereotypes useful. No one jokes with C code ending in "}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}", though I'm sure we've all seen that at some point. - finitud
(1) no C is more like oops I forgot the ; let me C it says the error is online 12 but it's actually on 13 - zeitue
(1) C-code ends with }}}}};}}};}}}}}} ☺ - Arne Babenhauserheide
(4) I wrote this answer 4 years ago, and now that I've joined the FP camp it makes me sad. - Chad
6
[+11] [2009-12-04 17:20:19] David Thornley

There are the basic arguments against porting any very large project to a very different implementation.

Right now, we've got a whole lot of C code that is extensively used and battle-tested. Rewriting that in any different language is going to introduce bugs. Lots of them. It would be years before the rewritten kernel would be anywhere near as good as the original.

Moreover, in order to get any benefit from it, it would be necessary to simply rewrite large portions of it to take advantage of Lisp's greater expressiveness. That increases the amount of effort and the number and severity of bugs introduced.

At the end, we'd have a Linux kernel designed in C and written in Lisp. I just don't see a great benefit here.

Moreover, the people most familiar with the kernel are experts in C, and there are a whole lot more C developers than Lisp developers, so you'd be changing the people working on it to a much smaller and less experienced group.

The right way to do something like this is to forget about rewriting, and simply write a new Linux-compatible kernel in SBCL. Look at the complete ABI for the Linux kernel at some version, determine what it needs to do, and treat those as specs for the SBCL kernel. It will wind up well behind the Linux kernels available when the project's finished, but if writing the kernel in SBCL does work as you hope it should be possible to catch up. The proof of whether this is worthwhile or not will be any acceptance of the new kernel.


7
[+11] [2009-12-04 17:50:15] Jerry Coffin

The short answer is that the reason it hasn't been done is that nobody has done it. If somebody (e.g., you) wants to do it badly enough, there's nothing to stop them/you from doing so. You never know: the project might be a wild success, and someday I'll be able to say: "I was the one who really got him to do it..."

At the same time, I feel obliged to point out that most attempts at starting open source projects seem to fail, and at least to me this one seems more like to fail than most others. The single biggest shortage (in most cases) is people to sit down and just hack out large quantities of code, most of which is ultimately pretty boring, but still has to be written (and written quite well at that) before you get a working system. The relatively small number of competent Lisp hackers leads to a bit of a problem right away. Unfortunately, an OS can't avoid a fair amount of code that has to work close to the "metal", and it's often (usually?) difficult to use a lot of higher level features to keep such code as compact and elegant as you might otherwise do. In other words, for things like device drivers, you're probably not going to gain as much from using Lisp as you'd expect from writing other kinds of code.

Then you have to find a development system (or more than one) that's suitable for the task. Something that lets you generate output that can run without any assistance from anything else at all. While there's no question that such a Lisp development system could be written, I'm not at all sure that there is such a thing (especially one that's freely available) today.

Third, you have to deal with the fact that many Lisp hackers have a relatively narrow view of the world. Many of them tend to latch onto very specific problems, and want to solve those problems as close to perfectly as humanly possible. Especially in the early development of something like an OS kernel, nearly the opposite is needed: write something that's barely usable as quickly as possible, so you can work on the other 10 zillion things that need to get done, and have something that's finished and working before it's obsolete.


8
[+9] [2009-12-04 16:24:02] Earlz

Are you sure you don't mean "all the things that can't be done in Lisp can be done in Assembly"?

The reason that the linux kernel was written in C in the first place was because C is a systems programming language. It is basically the equivalent of machine independent assembly code.

Porting the entire linux kernel to Lisp would be quite the undertaking.. I'll see you in about 5 years or more..

You can write a kernel in almost any language, but you must remember that some are more suited than others. C was designed just about for writing kernels. Lisp wasn't. Sure, it's possible, but it will be harder, no matter how much cleaner you consider the syntax. And you will still have to have assembly bits here and there for doing machine specific stuff(loading GDT, IDT, inport, outport, Interrupt stubs)

I assume that Common Lisp can be compiled. It would be much harder if it was interpreter only, as you would first have to port a Lisp interpreter(written in C or Assembly or some other "native" language) to bare-metal, which is basically like writing a kernel to load your kernel.


(4) Sbcl is bootstrapped, compiled purely in sbcl, so that part is already done. - rplevy
(2) To be specific, C was written to write the UNIX kernel in (replacing B). - Powerlord
Although, as Jerry Coffin pointed out when I accidently hit Add Answer insted of Add Comment, "B was never used to write a UNIX kernel. B was only ever put to minimal use, and only for some small utilities." - Powerlord
(1) @rplevy, Thats quite interesting.. it means to compile your kernel inside your kernel, you'd have to have a Lisp compiler.. but thats the same as with C and gcc and yes, B was used quite briefly, but it was still used(I believe the first versions of cp, ls, ed, and other common utilities were written in it) - Earlz
(4) Most good Common Lisp implementations have compilers. Some don't even have interpreters, and simulate it by JIT compiling. Replacing C with Lisp wouldn't be for the syntax, but for more general advantages. In general, Lisp is a much more expressive language than C, and would likely result in a much smaller kernel by LOC. Whether the general advantages of Lisp would compensate for C's closeness to the metal, in performance and in expressing all the stuff you need in the kernel, is a very large question. - David Thornley
9
[+9] [2009-12-04 17:33:58] Pillsy

It would be pointless. This isn't because Lisp can't be used to write an OS (there are existing examples of OSes written in Lisp!) but because rewriting big, complicated pieces of software just because you like some other language better is an extremely good way to waste money, effort and time.


10
[+8] [2009-12-04 20:25:00] L33tminion

Other posters have enumerated the problems with designing a kernel in Common Lisp (or SBCL specifically). And there are many good reasons why porting the Linux kernel to another language is almost certainly a bad idea.

That said, if you were picking a language in which to write a new kernel, Lisp has something very strong going for it: A Lisp-style macro system is incredibly useful in large-scale software systems. I've found that the resulting code can be much shorter, clearer, and easier to optimize.

If I were implementing a kernel, though, Common Lisp still wouldn't be a first choice. For one thing, I'd also like a strong type system, and if the language in question had garbage collection, I'd want that to be more efficient and predictable than the garbage collection in SBCL evidently is.

(Note: I use Common Lisp for hacking on a large-scale project at my job, but I know little about the Linux kernel or the internals of SBCL, so my knowledge about the flaws of SBCL garbage-collection is second-hand.)


11
[+4] [2009-12-04 17:01:59] Paul Nathan

I don't know that it could be ported. The language paradigms themselves are quite different. I would say that having a Linux-compatible clone that maintained interface/binary compatibility for drivers and applications is doable.

Why is Linux in C? Because C compilers exist for pretty much every architecture under the sun. Further, the writer of Linux famously prefers C.


12
[+3] [2009-12-06 09:37:35] lnostdal

It would be much more worthwhile working towards making Linux & SBCL (or some other Lisp if you want) communicate better with each other.


13
[+2] [2009-12-05 17:20:17] wgl

Certainly an OS can be written in Lisp. It is not clear what the point of rewriting Linux in Lisp would be, however. There are certainly enough competent resources dedicated to making Linux highly useable, effective, and popular.

The suggested benefit of being transparent is likely a non-issue, as you can see all the source code, read it, ask questions about it. If it appears to be not "transparent", it is likely that is because it is a very ambitious project that accomplishes a tremendous amount. So the problem of transparency is really one of familiarity. Read the code until you understand it. Even if you get an 8-fold reduction in LOC (a sheer guess) then it will still be a significant task to wrap your head around.

Regarding Lisp being as performant as C, this may not be as true as that statement implies. Certainly we can look at the microbenchmarks to see how they compare on small problems, but the real traction of improved performance would be found in really large engineering efforts where strengths of Lisp make a bigger difference.

Perhaps Linux focuses too much on the 1% performance differences. There have been good suggestions made about how to improve the reliability of the kernel and reducing its monolithic nature (cf Tannenbaum), and these are met with rigid resistance.

I think a more interesting question would be to approach the idea of an OS fresh and ask what we want it to do. Is there something more interesting we can do with a Lisp-based OS that Linux is not doing? If so, what about all the programs that you would want to run that require Linux or Unix ABI?


14
[+1] [2010-03-14 01:28:55] Silvanus

Wouldn't it be much more feasible to write lisp macros for generating C code for the Linux kernel, and slowly replacing original C source files?

... Hmm, I might just try that out and see if there are great advantages (I'm not the most experienced lithper T_T). Would there be any great licensing problems in committing generated C code? What if I tweaked it? Not so much that I'd be unhappy to release it, just.. I'm not sure there are any kernel developers who'd enjoy building my lisp code.


15
[+1] [2012-06-22 07:33:06] Little Jack

I think, like me, he want a total environment in Lisp, but it won't be nessesary written in Lisp. It can still based on a Linux kernel for low-level handling and still can interact with the high-level functions in Lisp.

The Trade-off here would be much lesser than written an entire OS in Lisp to get that "Full-fledged" Lisp OS. In this case, Hybrid C & Lisp is a very wise choice.


16
[0] [2010-05-15 22:52:34] jrernst

I strongly disagree. It is possible to use Lisp to write a linux kernel. The key is not to run it in Lisp. Imagine the kernel written in Lisp. Then transform this code to C with a mapping function. Then compile C and that's it. You gain: verification of the kernel in Lisp. No errors in C because C code is generated. You only have to prove that your mapping is correct.


17