Submitted by Captain, we’ve encountered another one. FreeNOS is a microkernel-based operating system written for learning purposes. “The system is very experimental, yet it currently supports virtual memory, simple task scheduling, and interprocess communication (IPC). It currently contains support for a few devices, including VGA, keyboard, i8250 serial, and PCI host controllers. FreeNOS has an experimental implementation of several filesystems, such as the virtual file system, procfs, tmpfs, and ext2fs. Current
application libraries include libposix, libc, libteken (terminal emulation), and libexec (executable formats). All source code has been documented with Doxygen tags.”
As the headline so eloquently revealed, version 0.0.3 of FreeNOS has been released, and it comes with the following improvements – among other things:
This version includes a new filesystem written from scratch: LinnFS. It is roughly based on the Extended FileSystem. It is now used as the root
filesystem on the LiveCD instead of Ext2. Additionally, the notion of current directory
has been implemented. Finally, this release has also been tested on the latest Nexenta distribution.
You can download this release from the project’s download page. Even though many question the usefulness of such projects, I’m a proponent for as many of them as possible. It means people are still interested in operating system design, even the really nitty-gritty low-level stuff.
No comments? How sad.
I took a quick look at the SVN repo and was surprised to see the kernel is written in C++. Not only that, but the code is very clean and readable. As a result of using STL classes for stuff like lists & queues the entire kernel code base appears to be tiny: bear in mind that the large portion of any kernels time is spent creating, modifying and iterating lists and arrays!
So, a microkernel written in C++…that could just alienate almost every OS developer on the planet. Good for them!
Yes, I always wondered why there is so much aversion against C++ in the kernel world. I think the language can abstract a kernel a lot, make segmentation faults a real choir to produce, and allows the kernel to be easily extended without rewriting large parts of code or resort to ugly hacks.
I really can’t believe speed is an issue. I think it’s an flawed excuse for conservative programmers.
One of the reasons I have heard (this isn’t my opinion btw – so any idiots out there who want to moderate me down claiming to me by opinion – jump off a cliff head first) are when projects become large C++ apparently has a habit of becoming rather unreadable and problematic. Personally I think that reason is more born out of a refusal by some to learn C++ but I could be wrong.
Writing it in C++ isn’t new though, there are lots of kernels in the commercial world that make extensive use of C++ (I/O kit in Mac OS X for example which is based on embedded C++) so I guess it has more to do with C being the first taught at many universities. Although when I went through polytech we were taught basic programming fundamentals in Visual Basic but then moved to teaching C++ as the ‘proper language’ (visual basic was only a teaching tool).
I must admit that C++ is often the one and only reason why I won’t get involved in some projects I otherwise admire. Like Haiku and perhaps this FreeNOS too.
I won’t go into details why, but perhaps I’ll summarize that for kernel development, C++ offers too much with too little gain.
For an interested reader, the internet is full of debates where some of the most prominent kernel developers of today debate the usage of C++ in kernels. Interesting reading.
Unfortunately I find that the debates that do occur descend into nothing more than Micro-kernel versus monolithic, RISC versus CISC etc. where technology fundamentalism rages rampant when the reality is that a combination is more in tune with what is required. What ever the case maybe I guess there are attempts to find the holy grail of languages – the language that can slice, dice, a salad topping and a floor polish all in one.
I tend to be out of step in that I still prefer the idea of a language that has a niche and does that niche incredibly well instead of having a general purpose language that is either an attempt to be everything to everyone that collapses under its own weight or worse no one is happy because it tries to do everything but ends up doing it all half assed.
Well said.
And then breaking this fine sentence into two parts that highlight my personal opinion:
C.
C++.
Language flame wars aside, there is really one simple technical reason why C is almost always chosen over C++ for kernel development.
At the kernel level, you’re running on the bare metal and you have to provide all functionality from scratch. The features of C++ depend heavily on a runtime to handle things like RTTI, exceptions, global/static initialization, memory allocation and constructors/destructors, among other things. So in order to build a kernel in C++ and take advantage of its features, you have to hoist a whole runtime into the kernel at the earliest moments of the boot process. You can use C++ without those features, but once you strip out enough of them, you’re basically left with C anyway. So the path of least resistance is to start with C, since it is still mostly functional without the runtime, and implement the features that you need as you go.
To use Linux as an example: the kernel does not link to glibc and the C standard library is not available other than specific functions which were implemented internally in the kernel.
Except of course that only RTTI and exceptions requires the runtime, constructors and destructors are just syntactic sugar for function calls at the right places. Global/static initialisation is also compile-time, memory allocation you have to manage in every OS and using C++ does not make it any simpler nor harder.
No, the real reason is probably that a couple of years ago when the debate started the computers were quite slow and memory quite expensive (compared to today’s computers) and C++ compilers were quite bad. You simply could not afford the less optimal code that the C++ compilers generated. Today that is not a problem, a lot of time, money, and effort has gone into making efficient C++ compilers and I would say that most energy is put on making C++ compile well and not C (remember that both Intel and MS sells C++ compilers, even though they can compile C too (well, at least Intel’s can)).
Developers in general (and the Great Mister L in particular) strongly believe that one cannot develop efficiently in C++.
Unfortunate indeed because that C++ “disadvantage” is yet to be proven and only exists in theory. Yes, sure, there is some internal language-overhead involved, however that may be dwarfed compared to the inefficiencies introduced when adding additional layers of features down the road while using straight-up C… At least C++ gives you means to evolve any piece of code very, very nicely w/o the need to re-write everything.
But that’s just my opinion – I’m no Kernel developer, at least not yet.
So long.
You can “hand tune” C code to be faster, because C compilers are less smart (and hence more predictable and mature). There is also lots of things C++ code does in the background (unless you are careful to avoid it) that you have to do manually in C (hell, the fact that you need to do everything manually in C is what makes it a bad app development language).
The eCos kernel is written in C++, but they had to take care to use only a safe subset. Everything is compiled without exceptions or RTTI. Still, they had to implement a C++ run-time in the kernel to get static constructors to run at the right time and in the right order. C++ does complicate things.
Microsoft has a good article on what to be aware of when writing kernel code in C++: http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx . Most of these concerns don’t affect eCos because eCos doesn’t use the MMU.
Useful project. Only if they decided on using either tabs or spaces, preferably the latter, as now they’re used randomly (given readability is priority #1).
Nice project indeed, although it looks like a linux-fork.
L4::Pistachio is another microkernel written in C++. http://l4ka.org/projects/pistachio/
Although L4 looks, from the original papers, like a really promising and practical microkernel I’m generally a bit hazy on what all the different implementations of L4 nowadays have to offer relative to each other.
I looked at the FreeNOS site and I did not see any provision for booting on a PC, only virtual environments. Is this the case? Are there plans for a PC bare metal boot?