OSDev.org

This is a quick post describing (in theory) - the pro's and con's of Python for an OS development scenario.

Pros
- Automatic memory management (well you kinda get that with C++)
- Big-number support on the fly
- Very good for portable code (multiarchitecture)
- Readability (if correct C glue is applied of course)

Cons
- Automatic memory management (sometimes that allocation wasn't intended to be scoped...)
- Nobody knows what python uses to disguise their variables, is it a string!?, is it a number!?, who knows!. It better be a short int or the whole MMIO code breaks!
- No pointers (but C<->Python glue can be put all over the place to fix this)
- Readability, sure, python is super easy and understandable, however Python is not C (too much C glue)

In the end, Python can be useful as a "driver prototyper" - it can help to quickly develop drivers if the C interface is good enough and can actually live in harmony with the rest of the OS.

However a Python-only OS is not too bad either - except for performance of course - and that perhaps there will be too many C wrappers all over the place.

I'd think it could even be practical that some drivers for an operating system written in C are first written in Python - not only this reduces coding time but it also makes everything 10's easier. This is of course, that the operating system supports it or supports dynamic libraries to mess with the driver interface.

:)

NetBSD supports kernel-level drivers written in Lua, so it's certainly something worth considering or messing with.

Though in a microkernel design, drivers could be theoretically written in any language, as long as the proper syscall wrappers exist.

SuperLeaf1995 wrote:Python for an OS development

Not possible, because Python is an interpreted language. This means, all that you have listed as "pro", must be implemented by you and must be supported before you could actually use Python on bare metal.

You have to implement
- the Python interpreter/JIT (or a crafted native bytecode cross-compiler for Python) as well as
- the run-time library and
- low level libk for the features that Python can't express (lgdt, paging etc.)
in a language that's not Python, probably C or Assembly. Once you have the running environment, then implementing some parts of the kernel in Python might work, but that's not "Python for OS development".

Cheers,
bzt

No reason you can't build a Python-to-native compiler, skipping the need of an interpreter or JIT. But even after that, you'll still need to step outside of standard Python to support manual memory management, which is a requirement (think peek and poke statements or functions).

bzt wrote:but that's not "Python for OS development"

No, look at all of the C# OSes out there. They have a tool which converts IL to native code. Same goes for Python.

Once you have that, you could have a small assembly library contains peek and poke functions.

Just because its hard doesn't mean it isn't possible, remember that.

bzt wrote:

SuperLeaf1995 wrote:Python for an OS development

Not possible, because Python is an interpreted language. This means, all that you have listed as "pro", must be implemented by you and must be supported before you could actually use Python on bare metal.

You have to implement
- the Python interpreter/JIT (or a crafted native bytecode cross-compiler for Python) as well as
- the run-time library and
- low level libk for the features that Python can't express (lgdt, paging etc.)
in a language that's not Python, probably C or Assembly. Once you have the running environment, then implementing some parts of the kernel in Python might work, but that's not "Python for OS development".

Sure it is. Just because Python would require some support to handle hardware interaction, doesn't mean to say it's not "Python for OS development".

If you applied that same logic to C, then you can't use "C for OS development", because you'd need a low level libk for features C can't express (lgdt, paging etc.).

Almost any language an OS is implemented in will require some lower level interface to handle actual hardware. C is no different to Python on that front.

All that said, I'm not certain it is a great idea beyond user level drivers or embedded implementations like micropython.

bzt wrote:

SuperLeaf1995 wrote:Python for an OS development

Not possible, because Python is an interpreted language. This means, all that you have listed as "pro", must be implemented by you and must be supported before you could actually use Python on bare metal.

You have to implement
- the Python interpreter/JIT (or a crafted native bytecode cross-compiler for Python) as well as
- the run-time library and
- low level libk for the features that Python can't express (lgdt, paging etc.)
in a language that's not Python, probably C or Assembly. Once you have the running environment, then implementing some parts of the kernel in Python might work, but that's not "Python for OS development".

Cheers,
bzt

Of course it's interpreted, nobody said that coding a Python OS would be easier than a C OS ;) - Python can still "grab" some high-level logic, for example the vfs of the operating system could be implemented in Python with (as i said, C glue, otherwise it's impossible), however this introduces a chicken-egg problem if the Python interpreter expects a working fs - The need of C is known, Python cannot live by itself because welll... a language without pointers is not very low-level, does it?

A "Python OS" would need a big chunk of C code anyways, or do some sort of transpilation of the code - It's like Java OS, they still need non-Java for the job

You might be interested in one of my side projects:

The truth is that you can write an OS in any language, regardless of whether its interpreted or not. So long as the language environment supports what your operating system supports, go for it. ou could do it in Go, Perl, Python... You name it. You'll need to write the underlying runtime environment support, however, and you may need to write extra libraries to handle low-level operations. But its most definitely possible. It would just require a lot of work, and you really have to ask yourself if it'd be worth it. If you wanted full Python support -- standard library and all -- then by the time you finished implementing the necessary run-time support for that you'd have completely written an OS -- even if your scheduler is primitive. But you could easily then build all your OS services and infrastructure on top of that implementation and rarely ever touch C (or insert your systems language here).

rossjulie wrote:I still stand with python.It easy to learn and make adjustments and improvements unlike C++

You might want to check out GO language, it is compiled but easy to write.

A friendly reminder that even a kernel written in C requires some level of assembly. For example, my entry point that sets up a temporary paging structure and jumps to long mode, or my interrupt handlers.

Now, you could compile Python to machine code, but you'd need a Python runtime that supports things like memory allocation and garbage collection.

A purist method would be: Implement a Python runtime in assembly, and run Python in your kernel. (In my opinion, writing a garbage collector in pure assembly would be super difficult.)

A non purist method would be: Start with a unikernel such as #include <os> or Unikraft, where the entire OS is treated like one large C++ application. Then embed a Python interpreter into your OS.

If I were to undertake this, I'd treat the unikernel + Python interpreter as a "micro-kernel". Offer some basic support such as threading, a mechanism for sending messages between Python running programs, and exposing some way of interfacing with io ports and memory mapped hardware in Python. Then implement all of your programs and microkernel services (the window manager, the file system, the hard disk driver, etc.) in Python.

AndrewAPrice wrote:A non purist method would be: Start with a unikernel such as #include <os> or Unikraft, where the entire OS is treated like one large C++ application. Then embed a Python interpreter into your OS.

Or you can do what Intel did and shove it in Grub: https://biosbits.org/

But why embed CPython when you can build your own Python interpreter from scratch...

If you dislike the idea of a huge C or assembly runtime, another option is to invent a "Systems Python" language that is basically a variant of Python with the minimal amount of work to make it statically typed/manual memory management while still having the look and feel of Python. Bonus points if your code is actually valid Python too.

Write your core microkerne/runtime n "Systems Python" with all applications and services in regular Python.

Building an OS in Python would be impressive and a noble feat.

All of the above suggestions require a lot of engineering effort. You still have the same troubles as building a kernel in C (paging, scheduling, messaging, memory allocation, IO, interrupts, etc) but now you have to build a Python runtime.

One of the pros you listed for Python was garbage collection, but you don't get garbage collection for free, you have to implement the garbage collector yourself (as part of your Python runtime, even if the Python is compiled to native code) on top of all the other technical challenges of building an OS.

I'm using C++, but I don't get std::thread for free in my OS. It was a lot of work to support threading in the kernel and porting a C and C++ standard library to my OS.

The dynamic type system, the dictionary operations, the memory allocation of Python that is taken for granted, all requires runtime support. The reason C is super popular for OS development is that just about everything in the language (if you don't depend on the standard library) doesn't require runtime support.

A Python OS project would be super cool, but it is a big undertaking, so I want you to make sure your motivation is correct and that it's not because you think Python is an easier language to use than C.

The Python interpreter (CPython) doesn't support multi-threading. That would be a huge impediment to writing on OS in Python. You could try to adapt PyPy, but that would be an enormous undertaking.

So either you go with CPython and forgot multithreading, or you write your own Python interpreter. The later is probably a better way to go about it. It is a lot of work, arguably more work than writing a kernel.