Python Operating System???

[Arich Chanachai]

...


Huh? That's a non-sequitur, nothing prevents you from running Lisp on
your PC or Mac. The same issues issues that apply to OS code, also
apply to user code. The Lisp machine hardware wasn't needed only to
make the OS run fast. The Lisp machine was developed so that people
could deploy large user-level applications written in Lisp, and the
hardware was there to support those applications. And given such a
good Lisp environment, there was no reason to think of writing the OS
in anything other than Lisp.

In fact, the reason the Lisp machine died off was because general
purpose workstation hardware (and later, PC-class hardware) became
fast enough to run Lisp applications without needing special purpose
CPU's. That same PC hardware speed is what makes it possible to run
user applications in Python.

So true, there was indeed a contextual reason for special hardware, and
the context has since changed (dramatically).

 

[Roose]

I've written file systems in Python, and task schedulers in

Javascript, and they were fine for their purposes

Uh, not to be rude, but what are you talking about? If I'm not mistaken
Javascript is that scripting language that runs inside a browser, an
application. How are you going to save and restore CPU state in Javascript,
or even call assembly that does it in Javascript? How do you switch into
kernel mode in Javascript? We are on completely different pages apparently.

Huh? That's a non-sequitur, nothing prevents you from running Lisp on
your PC or Mac. The same issues issues that apply to OS code, also
apply to user code. The Lisp machine hardware wasn't needed only to
make the OS run fast. The Lisp machine was developed so that people
could deploy large user-level applications written in Lisp, and the
hardware was there to support those applications. And given such a
good Lisp environment, there was no reason to think of writing the OS
in anything other than Lisp.

Upon reading back in the thread I see that you mean compiled Lisp, no? I
was thinking that there would be a Lisp interpreter in a kernel, which afaik
doesn't exist. In any case, as I said before I don't think it is
impossible, just a poor engineering decision and I don't see the rationale
behind it. Sure you can do anything for intellectual purposes and you'd
probably learn a lot, but the OP is looking for an easier way to write an
OS -- and that is not to write it in Python.

 

[Paul Rubin]

Uh, not to be rude, but what are you talking about? If I'm not mistaken
Javascript is that scripting language that runs inside a browser,
Correct.

an application. How are you going to save and restore CPU state in
Javascript, or even call assembly that does it in Javascript? How
do you switch into kernel mode in Javascript? We are on completely
different pages apparently.
Correct.

Upon reading back in the thread I see that you mean compiled Lisp,
no? I was thinking that there would be a Lisp interpreter in a
kernel, which afaik doesn't exist.

Yes, compiled Lisp. There are Python compilers too.

In any case, as I said before I don't think it is impossible, just a
poor engineering decision and I don't see the rationale behind it.

I don't see a convincing case against writing an OS even in
interpreted Python, though of course I'd want it to be compiled if
possible.

What do you think OS's do, that Python wouldn't be suitable for? Your
examples of task switching and virtual memory are unconvincing. Those
just require setting up some suitable tables and then calling a
low-level routine to poke some CPU registers. File systems can be
more performance intensive, but again, in those, much of the cpu drain
can be relegated to low-level routines and the complexity can be
handled in Python.

 

[Arich Chanachai]

...


Yes, compiled Lisp. There are Python compilers too.\

??? You mean like Pyrex or some such? I wouldn't exactly call these
"Python" compilers, as that kind of obscures some underlying (critical)
facts.

I don't see a convincing case against writing an OS even in
interpreted Python, though of course I'd want it to be compiled if
possible.

What do you think OS's do, that Python wouldn't be suitable for? Your
examples of task switching and virtual memory are unconvincing. Those
just require setting up some suitable tables and then calling a
low-level routine to poke some CPU registers. File systems can be
more performance intensive, but again, in those, much of the cpu drain
can be relegated to low-level routines and the complexity can be
handled in Python.

Correct.

 

[Paul Rubin]

??? You mean like Pyrex or some such? I wouldn't exactly call these
"Python" compilers, as that kind of obscures some underlying
(critical) facts.

Also psyco. And I think Pypy is currently set up to compile Python
into Pyrex and then run the Pyrex results through GCC.

 

[Roose]

Correct.

Are you actually going to answer any of my questions? Let's see this
"JavaScript task scheduler" you have written! I'm calling bullshit on that,
seeing as you declined to say anything useful about it. But I'm open to
learn anything. Let's see it. Until then I'm not sure I want to spend a
lot of energy arguing with you, because you're either pulling my leg or just
profoundly mistaken.

 

[Paul Rubin]

Are you actually going to answer any of my questions? Let's see
this "JavaScript task scheduler" you have written!

I wrote it at a company and can't release it. It ran inside a
browser. There was nothing terribly amazing about it. Obviously the
tasks it scheduled were not kernel tasks. Do you know how Stackless
Python (with continuations) used to work? That had task switching,
but those were not kernel tasks either.

 

[Arich Chanachai]

Also psyco.

Directly to machine code---- how could anyone say this is not compiled
Python. I am right with you. On the other hand however, its
compilation occurs on-the-fly (JIT) and is no more compiled than Java.
There is an argument either way. I have heard of Java OSs in the works
and possibly already existing...are these pure Java?

And I think Pypy is currently set up to compile Python
into Pyrex and then run the Pyrex results through GCC.

But of course, who's going to argue that Pyrex produces "compiled
Python"? I expect many would beg to differ, and in fact might like to
kiss your toes just for the mere pleasure of contradicting and arguing
against any assertion that Pyrex produces "compiled Python".

 

[Paul Rubin]

But of course, who's going to argue that Pyrex produces "compiled
Python"?

Pyrex produces compiled Python in the same sense that asm produces
"compiled C". PyPy contains a Python compiler which reads Python
source and produces Pyrex output. The Pyrex output then gets compiled
by the Pyrex compiler and then the C compiler before ending up with
machine code. There is nothing terribly bizarre about this kind of
compiler. For example, Gnu Common Lisp compiles Lisp code into C,
then runs the C code through gcc. For that matter, the Yacc/Bison
parser generators do something similiar.

 

[Michael Sparks]

Roose wrote:
....

I was thinking that there would be a Lisp interpreter in a kernel,
which afaik doesn't exist.

There's an implementation of scheme that runs as a kernel module in
Linux - it's designed to allow people to experiment with exploring
kernel data structures at run time, and other fun things.

It's a case in point for avoiding saying that something that doesn't
necessarily sound sensible doesn't exist - there's a good chance it
does


Michael
--
(e-mail address removed)
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

 

[Arich Chanachai]

<Lots of bickering and just plain good sport snipped out>

What I really wonder about is the possibility of integrating Mono with a
kernel and building upward (the "shell" if you will) using IronPython.

 

[Roose]

I wrote it at a company and can't release it. It ran inside a
browser. There was nothing terribly amazing about it. Obviously the
tasks it scheduled were not kernel tasks. Do you know how Stackless
Python (with continuations) used to work? That had task switching,
but those were not kernel tasks either.

Well, then of course you know I have to say: An OS does not run inside a
browser. There's a sentence I never thought I'd utter in my lifetime.

So that is an irrelevant example, since it obviously isn't a task scheduler
in the context of this thread.

Anyway, this argument is going nowhere... I will admit that people have
pointed out things here that are interesting like the attempts to embed
Python in a kernel. But the point was that the OP was looking for an easier
way to write an OS, and thought that might be to do it in Python, and I
think I gave some good guidance away from that direction. That is mostly
what I care about.

These other arguments are academic, and of course I am not trying to stop
anyone from trying anything. When I we see real working example, then we
will all have a better idea of what the problems are, and how much of it can
realistically be implemented in an interpreted language. Frankly I don't
think that will come for about 10 years if ever, but hey prove me wrong.

 

[Paul Rubin]

Well, then of course you know I have to say: An OS does not run inside a
browser. There's a sentence I never thought I'd utter in my lifetime.

So that is an irrelevant example, since it obviously isn't a task scheduler
in the context of this thread.

Huh? I'm just baffled why you think writing a scheduler in an OS is
harder than writing one in an application. You have some means of
doing a coroutine switch in one situation, and some means of doing a
hardware context switch in the other. Aside from that the methods are
about the same.

Why do you think there's anything difficult about doing this stuff in
Python, given the ability to call low level routines for some hardware
operations as needed?

 

[Roose]

Huh? I'm just baffled why you think writing a scheduler in an OS is
harder than writing one in an application. You have some means of
doing a coroutine switch in one situation, and some means of doing a
hardware context switch in the other. Aside from that the methods are
about the same.

Because of performance. Task schedulers and device drivers tend to be
timing sensitive. Go look up "task schedular latency". The longer your
scheduler spends trying to figure out which thread to run, the longer the
latency will be.

I mean in the worst case, if you are interpreting everything, what if you
change the task scheduler code? Then an interrupt happens, and oh shit we
have to parse and recompile all the scheduling code. Oh wait now we ran out
of kernel memory -- now we have to run the garbage collector! Let your
interrupt wait, no?

It just seems nonsensical. Maybe not impossible, as I've already said. I
haven't tried it. But go ahead and try it -- I would honestly be interested
in the results, all kidding aside. It shouldn't be too time-consuming to
try, I suppose. Get Python running in the Linux kernel, and then replace
the task scheduling algorithm with some Python code. See how it works. I
suspect you will degrade the performance of an average system significantly
or unacceptably. But who knows, I could be wrong.

Of course, hardware is getting faster as you say. But multitasking
performance is still an active and important area of OS research, and I
doubt that any designer of an OS (that is actually meant to be used) would
spend any cycles to have their task scheduler in Python -- and that will be
probably be true for a very long time. Or maybe I'm wrong -- go bring it up
on comp.os.linux or whatever the relevant newsgroup is. I'd like to hear
what they have to say.

 

[JanC]

jtauber schreef:

see http://cleese.sourceforge.net/

There is not much to see there, most of the wiki is filled with spam...