Python OS

[Richard Blackwood]

<SNIP>

>
> I'm really not trying to contradict nor stir things up.  But the OP 
> wanted to know if it were possible to prototype an OS and in a 
> follow-up, referred to a virtual OS.  Maybe I mis-read the OP, but it 
> seems that he is not concerned with creating a _real_ OS (one that 
> talks directly to the machine), it seems that he is concerned with 
> building all the components that make up an OS for the purpose 
> of....well.....he didn't really state that.....or maybe I missed it.

You understand me entirely Jeremy.  The goal is to create a _virtual_ OS 
that will represent and behave (minus speed) like a  real OS.  It will 
be comprised of all the components necessary for a _real_ OS and if the 
only way to do it is to simulate hardware as well, so be it.  If the 
only way to do it is to handle _real_ interrupts via excruciating slow 
Python to C calls, so be it.  So you understand me entirely as I do not 
wish to create an OS that is usable in the traditional sense.

>
> So, asking in total ignorance, and deferring to someone with obviously 
> more experience that I have (like you, Peter), would it be possible to 
> create an OS-like application that runs in a Python interpreter that 
> does OS-like things (i.e. scheduler, interrupt handling, etc.) and 
> talks to a hardware-like interface?  If we're talking about a virtual 
> OS, (again, I'm asking in ignorance) would anything really be totally 
> time critical?  Especially if the point were learning how an OS works?

Time is not an issue.

>
>>
>> Given that the cost of invoking the Python interpreter on
>> a bytecode-interrupt routine would be several orders of
>> magnitude higher, I don't understand why you think it
>> is possible for it to be as fast.
>
>
> I totally agree with you...sort of.  I totally agree with your 
> technical assessment.  However, I'm reading the OP a different way.  
> If he did mean a virtual OS and if time isn't critical, and he was 
> thinking, "well, I'm getting shot down for proposing to do this in 
> Python, so maybe it isn't possible in Python, but it is possible in C 
> and since I can call C from Python, then I should be able to do it", 
> then maybe he has a point.  Or, maybe I'm just totally misreading the 
> OP.  So, if he's saying that he can just call the C code from python 
> and it'd be just as fast doing interrupt handling that way, then I 
> agree with you.  But if he's talking about just the functionality and 
> not the time, is that possible?

I agree as well, but somehow it was interpreted that I believe it 
possible to achieve the same speed in Python as in C, which I never 
said.  So again, you understand me entirely.  Functionality and not 
time, exactly.

>
>>
>> Of course, if you will allow both assembly/C code here and
>> there as a bridge, *and* you are willing to accept an operating
>> system that is arbitrarily slower at certain time-critical
>> operations (such as responding to mouse activities) than we
>> are used to now, then certainly Python can be used for such things...
>>
> OK - so here's my answer.  It should be possible, but it will be 
> slower, which seems to be acceptable for what he meant when mentioning 
> prototyping and a virtual OS.  But here's another question.  Would it 
> be possible, if I've interpreted him correctly, to write the whole 
> thing in Python without directly calling C code or assembly?  Even if 
> it were unbearably slow and unfit for use for anything other than, 
> say, a learning experience?  Kind of like a combustion engine that has 
> part of it replaced with transparent plastic - you dare not try to run 
> it, but you can manually move the pistons, etc.  It's only good for 
> education.
>
That is my question, but the consensus seems to be no.