Low level python

[Gustavo Cordova]

> > I've been thinking of writing a device driver in python.
> > 
> > Some people say this is ridiculous.
> > 
> > I used psyco to improve the speed, and now have a program 
> > that does the device driver's job (a proprietry touchscreen
> > driver) in user mode.
> > 
> > Now, I have no idea how to make the python exe or dll run in 
> > kernel mode. I wonder if there are some special api calls
> > that need to made.
> > 
> > I'm downloading WinDriver. I hope this can help me.
> > 
> > Does anyone not think this is a crazy thing to do?
> > 
> > Why not use python for a device driver?
> > 
> > I just see it as python dll is the driver, and the .py file are like
> > permanent configuration file for it.
> > 
> > Comments Appreciated
> > Matthew Sherborne
> 
> I think it's a fabulous idea.  I think you will find yourself writing
> a few python extensions, so be prepared.
> 
> Perhaps even a python operating system is plausable.  I'm not very
> knowledgeable about operating system design, but it seems as if
> some operating systems such as Windows suffer from a lack of a robust
> universal object model with garbage collection.  The idea would be
> to expose the kernel and low level interfaces as python extensions.
> As processors continue to move into the GHz zone, function call
> overhead becomes less significant, while scaleability and code
> complexity become more significant.
> 
> Well, now maybe people will call me crazy instead of you :-)
> 
> - Ken
> 

This is a *very* interesting project, and mightily seductive,
intellectually speaking.

BUT, one thing I differ in respect to the opinions expressed
by many of the folx here, is that 3mb for a device driver
seems to me awfully expensive --memory wise--, and, dangerous.

Dangerous, because there is lots of code which can hide bugs
in 3 Mb. Bugs which could, at the device-driver level, wipe out
the whole work of months, in a blink. We've all had our share
of flaky windows (3.x, 95, 98, NT, etc) drivers, and the heartache
and pain they cause (and lost time, and bloo screens of deth).

Do we really want that for our Python-written drivers? Is that
the reputation we wish to create?

Wait a sec, I'm not saying that Python may be flaky, on the
contrary, it's proven itself more than once, and the quality of
the PEOPLE behind it's development is superb. But mistakes are
maken, nobody's perfect.

That's what makes a driver written in C or in assembler (better
yet) such a beautiful thing: it's tiny, it ONLY uses what you
explicitly told it to use, and it's fast.

OK, after having my say about "the water's cold and you'll catch
your death", let's jump in the pool. :-)

Call me old fashioned ("booo!! hisss!! oldster!!!"), but writing
a device driver in an interpreted language doesn't really rub me
the right way.

I was playign around a few months back with Forth, a really neato
language, but even more illegible than Perl, if you can believe
that. BUT, it's really really appealing to anybody's hacker
instinct. Dangerously appealing, if you ask me.

One of the most neat things is that a complete Forth system,
compiler and all, is very small, and it's written in Forth itself.
Forth, written in Forth.

And, in a package I found, it comes with a machine language
assembler. Now *that* would be useful for our python device drivers.
A Machine Language Assembler module.


from Assembler import Ix86


So, you assemble a few instructions, which do all the low-level
stuff you need, and very quickly. Bit-fiddling is best done in
machine language.

Is this doable?

Can python eventually become self-hosting, like forth?

Can we do away with the C stdlib tyranny?

Can python eventually become it's own OS?

Sounds very interesting to find out.