OSDev.org

I've dabbled a bit in OS development, but after losing most of my bootloader code (twice!) and seeing just how many hardware devices I'd have to support on an x86 platform, I'm thinking that an ARM system would be a better platform for my first OS project. I'm specifically looking at the Raspberry Pi because I'll (hopefully) be getting my hands on one soon, and I'd have access to the graphics driver code I'd need. Anyway, I'm wondering if OS development really is easier for ARM systems. I know that keyboard support will be tough because I'll need a full USB stack, but it looks like it will take less driver development overall.

blm768 wrote:it looks like it will take less driver development overall.

No. The number of supported hardware is limited by your development cost (including time), but not the number of available hardware.
Just like there are infinite number of hardware on x86, which you never support all of them; there are also infinite number of SoC or external circuit for ARM-based system, yet you just select a few for your OS.

bluemoon wrote:No. The number of supported hardware is limited by your development cost (including time), but not the number of available hardware.
Just like there are infinite number of hardware on x86, which you never support all of them; there are also infinite number of SoC or external circuit for ARM-based system, yet you just select a few for your OS.

Good point. Let me rephrase that: "less driver development for the built-in hardware."

I'll probably let others worry about the drivers for most external devices; I can't write everything, after all. I will need to write decent keyboard/mouse drivers, though.

blm768 wrote:

bluemoon wrote:No. The number of supported hardware is limited by your development cost (including time), but not the number of available hardware.
Just like there are infinite number of hardware on x86, which you never support all of them; there are also infinite number of SoC or external circuit for ARM-based system, yet you just select a few for your OS.

Good point. Let me rephrase that: "less driver development for the built-in hardware."

I'll probably let others worry about the drivers for most external devices; I can't write everything, after all. I will need to write decent keyboard/mouse drivers, though.

I always wonder, is keyboard and mouse really suitable for ARM-based system (or decent OS with any architecture aim for years in future)?
For debug/development purpose, the serial console is pretty good. For user interface, traditional mouse is not enough but a multi-touch system.
Furthermore, I'm quite interested in near-field communication, which I may just build the network stack and delegate the UI to mobile phone or tablets, which sound comfortable to end user.

bluemoon wrote:I always wonder, is keyboard and mouse really suitable for ARM-based system (or decent OS with any architecture aim for years in future)?
For debug/development purpose, the serial console is pretty good. For user interface, traditional mouse is not enough but a multi-touch system.
Furthermore, I'm quite interested in near-field communication, which I may just build the network stack and delegate the UI to mobile phone or tablets, which sound comfortable to end user.

Alternative interfaces will definitely be something to consider, but someone is always going to want at least a keyboard, and I'll certainly want one for development.

I haven't played with serial console I/O. I assume that an Arduino would be an ideal device to interact with that.

Of course, before I can do that, I have to compile my toolchain. That's sure to be fun, especially since I'm trying to use the D programming language, the LLVM-based compiler I want to use only really supports Linux, and Qemu refuses to properly boot my Raspberry Pi image in Linux. I'm currently trying to compile everything in Windows. I must like pain.

blm768 wrote:Of course, before I can do that, I have to compile my toolchain. That's sure to be fun, especially since I'm trying to use the D programming language, the LLVM-based compiler I want to use only really supports Linux, and Qemu refuses to properly boot my Raspberry Pi image in Linux. I'm currently trying to compile everything in Windows. I must like pain.

On second thought, I'll use C for the kernel and worry about D when I get to drivers and user software. It's not worth the extra effort to make the kernel in D when I don't even have access to the runtime library. Since it's going to be a microkernel design (and as lightweight as I can possibly get it), C should be able to provide enough abstraction.

It looks like progress might be held up a while; Qemu is crashing on me, and I can't find another emulator with any level of Raspberry Pi compatibility. I might just have to wait until I can run it on hardware.

This is your decision, of course, but I'd suggest using a minimal amount of languages in a project. There's a good read by Brendan, which would partially explain why I think so. Plus, with every different language, you introduce the need for new compilers, and possibly other stuff.

Also, as for the kernel being lightweight, C is your friend here, unless you wanna go even further and write it in assembly.

Sandras wrote:This is your decision, of course, but I'd suggest using a minimal amount of languages in a project. There's a good read by Brendan, which would partially explain why I think so. Plus, with every different language, you introduce the need for new compilers, and possibly other stuff.

Also, as for the kernel being lightweight, C is your friend here, unless you wanna go even further and write it in assembly.

I'd be using D for the whole project, but I'd have to stub out the runtime for use in the kernel, which would make it hardly better than C for this problem domain. I don't want to do the whole project in C because once I can actually have the runtime library, D will be much better at providing powerful abstractions. It does introduce another language, but I think it's justified, at least when starting out. Once I've got my D compiler issues sorted out, it shouldn't be too hard to rewrite my C code in D, although I assume that most people who have any experience with kernel programming will be comfortable with C, so it wouldn't end up being much of an issue.

Your point is a very good one, but I think that my situation falls into one of the few exceptions to the rule. At least, I hope it does.

I definitely don't want to go all-out and write my kernel in assembly; C is a lot more readable than ARM assembly and about as efficient, and it will also be more portable. Besides, I really don't know much assembly.

Sandras wrote:Also, as for the kernel being lightweight, C is your friend here, unless you wanna go even further and write it in assembly.

Also, as for the kernel being lightweight, writing lightweight code in system programming language, and compiling it with -O3 or similar is your friend here, unless...

I think it's fixed now. The key part is that "system programming language" there; don't discriminate C++ (and probably some others I can't think of right now), which - using good compiler (as in G++/Clang++) and being written in lightweight form, not using features impacting performance in critical areas (such as multiple virtual dispatches in IRQ handler or something) - is similarly good as C for system programming.

Not to mention that it's prettier and superior </flameish mode>, but let's not turn this into yet another language flame war.

Griwes wrote:

Sandras wrote:Also, as for the kernel being lightweight, C is your friend here, unless you wanna go even further and write it in assembly.

Also, as for the kernel being lightweight, writing lightweight code in system programming language, and compiling it with -O3 or similar is your friend here, unless...

I think it's fixed now. The key part is that "system programming language" there; don't discriminate C++ (and probably some others I can't think of right now), which - using good compiler (as in G++/Clang++) and being written in lightweight form, not using features impacting performance in critical areas (such as multiple virtual dispatches in IRQ handler or something) - is similarly good as C for system programming.

Not to mention that it's prettier and superior </flameish mode>, but let's not turn this into yet another language flame war.

Aside from assembly, the language closest to most hardware, that I know of, is C. Here I value closeness to hardware by how well the language maps to machine code, not by how well a given implementation of its compiler can optimize. This is because, for whatever reason, a person might want to use a compiler different from the most optimizing one. In other words, a language is not its compiler.

Griwes wrote:Also, as for the kernel being lightweight, writing lightweight code in system programming language, and compiling it with -O3 or similar is your friend here, unless...

I think it's fixed now. The key part is that "system programming language" there; don't discriminate C++ (and probably some others I can't think of right now), which - using good compiler (as in G++/Clang++) and being written in lightweight form, not using features impacting performance in critical areas (such as multiple virtual dispatches in IRQ handler or something) - is similarly good as C for system programming.

Not to mention that it's prettier and superior </flameish mode>, but let's not turn this into yet another language flame war.

I'm not completely opposed to the idea of writing it in C++, but if I can get it in C while keeping the code readable, I'd like to do that. I guess I'll figure that out once I start implementing the scheduler or something. My main reason for not choosing C++ is that it's more complex than it really needs to be, but that's a debate for another time and place...

I'll probably get to a point where I miss classes and templates, though, and I'll probably give in.

blm768 wrote:Good point. Let me rephrase that: "less driver development for the built-in hardware."

No, there's potentially unbounded number of SoCs designs, each with it's own unique architecture and numerous details - see current ARM support unification effort in Linux kernel for interesting insights.

Sandras wrote:

Griwes wrote:

Sandras wrote:Also, as for the kernel being lightweight, C is your friend here, unless you wanna go even further and write it in assembly.

Also, as for the kernel being lightweight, writing lightweight code in system programming language, and compiling it with -O3 or similar is your friend here, unless...

I think it's fixed now. The key part is that "system programming language" there; don't discriminate C++ (and probably some others I can't think of right now), which - using good compiler (as in G++/Clang++) and being written in lightweight form, not using features impacting performance in critical areas (such as multiple virtual dispatches in IRQ handler or something) - is similarly good as C for system programming.

Not to mention that it's prettier and superior </flameish mode>, but let's not turn this into yet another language flame war.

Aside from assembly, the language closest to most hardware, that I know of, is C. Here I value closeness to hardware by how well the language maps to machine code, not by how well a given implementation of its compiler can optimize. This is because, for whatever reason, a person might want to use a compiler different from the most optimizing one. In other words, a language is not its compiler.

The closeness of mapping between the language and machine code makes sense only in few parts of kernel, and of course, in those parts, you write mainly C, even when writing C++ - PODs, raw and literal pointers etc. - but in some parts it doesn't matter what the machine code is; with proper abstraction, your scheduler shouldn't care about the machine in question - only the lower level constructs, like arch-specific context switcher etc. - so in those parts, you don't need mapping to machine code, but abstractions that are easy to work with.

I wrote a compiler. There are many things in C which make it easy for a simple compiler. Today, however, most compilers don't need them.
My compiler benefits from the first, but it shouldn't matter to a modern compiler. However, my compiler is very fast and it needs to be for JIT operation.

SparrowOS wrote:However, my compiler is very fast and it needs to be for JIT operation.

Great, but is that somehow related to this topic which I couldn't figure out?