I like operating systems and would eventually like to become a OS developer mostly working on kernels. In the future will C still be the language of choice and what else should I be trying to learn?
I think it's safe to say that low-level parts of operating systems (e.g. the kernel) will continue to be written in C because of its speed. Like mentioned elsewhere, you will need to know assembler for certain parts of the kernel (something needs to load the kernel into memory). But you can work on the kernel with little or no assembly knowledge. A good example would be if you're implementing a file system.
Don't worry about what language the operating system is implemented in. What's important is how an operating systems are used, and what can be done to improve them. A good example is when Unix first came out. The file system had the inodes at the front of the disk, and data in the remaining space. This didn't perform very well as you were seeking to different parts of the disk for all files. Then the Berkeley Fast File System was created to make a disk aware file system. This means having inodes near their corresponding data. I'm leaving out a lot of details, but I hope this illustrates that it's more important to think about how an operating system can be improved rather than what language it will be programmed in.
Some recent trends in operating systems are virtualization and distributed computing (see Google's paper on MapReduce). File systems, security, scheduling (especially with multi-core processors), etc are continually areas of interest even though these problems are not new.
Here are some resources if you want to learn more about kernel development:
- Linux Kernel Newbies - Resource for those who want to get started on modifying the Linux kernel.
- xv6 source - x86 port of Unix version 6. Used by MIT to teach an operating systems class. Simple, and easy to extend (more info).
- Linux Kernel Map - Call chain of system calls in Linux. Useful in visualizing what a system call does.
Bottom line: Start getting familiar with the kernel and read papers on what researchers are writing about (USENIX is useful for this). This knowledge is much more valuable than learning a new language, as most concepts from one language can easily be transferred to another if there does happen to be a shift in what operating systems are written. Hope this helps!
Among the research crowd, there is a lot of of interest in using language-based technology to guarantee that the kernel can't misbehave. A number of people have mentioned the Singularity project, which currently has a (deservedly) high profile. Why is Singularity interesting?
The language includes a finite-state model for the proper use of locks. The compiler can model-check the code against the model to be sure that deadlock doesn't happen.
Third-party drivers are given a limited interface to the system. The checking done by the compiler guarantees that a bad driver cannot take out the system---the worst it can do is knock out its own device.
Singularity uses compiler technology, not OS/MMU technology, to isolate one "process" from another. Suddenly forking a new "process" (really a new kind of protection domain) is dirt cheap, and this cheapness enables new designs.
Singularity is just the latest in a long list of projects that have used language and compiler technology to solve OS problems. One of my favorites was the University of Washington SPIN kernel, which allowed applications to extend the kernel safely and was written in Modula-3.
This area of research is still wide open, and it is not really known yet what set of language or compiler features is a "sweet spot" for solving OS problems. So to answer your question:
In today's production systems, C is still "it."
For the operating systems of the future, C is almost certainly not "it"—we know that it is possible to do much better—but the exact nature of the new "it" is still a wide-open question.
C is pretty much it, with a fair amount of assembler. Important topics for OS kernel work include:
- Principles of caching and cache management
- Virtual memory, TLB management
- CPU and system architecture
- Storage hierarchies
- Concurrent programming techniques (mutual exclusion, locking, ...)
- Algorithms and data structures
Actualy, there is quite a bit of room in the core of a modern OS for C++ code. I just looked and the Win7 core kernel tree has quite a bit of C++ code. Note that many sub-systems remain in simple C. There are a few reasons for this
- C is the original language of the NT based OS
- C is very, very well understood by key people
- Well written C can be the most straight forward code to debug - especialy in kernel mode.
That being said, many teams and people have found well written C++ to be an effective tool for core OS work.
There is nothing about C++ that prevents it from being used to write core resource management code like a scheduler, memory manger, I/O subsystem, graphics sub-system, etc. etc.
As others have pointed out - any kernel work will always require some bit of assembly language.
Microsoft is in the process of rewriting some of Windows in .NET however I doubt that much of the kernel will be touched.
However there are projects like Cosmos ( http://www.gocosmos.org/index.en.aspx ) which give us hope.
No, it is not "it". Kernels are generally written in C with a bit of assembler sprinkled in. But the OS is written in all sorts of language. But even there, C++ can be used without too much trouble. So can many other languages. Linux is written by C fanatics who fear and loathe everything else, which is their problem. Windows is written in a big mix of C and C++, and probably with a some bits of old Pascal code as well. And these days, chunks of .NET are turning up as well. OS X uses Objective-C for much of the OS code.
The same advice applies as in all other areas of programming:
- Know your stuff
- Don't limit yourself to the One True Language.
The kernel is the only area where somewhat "special" rules apply. But the kernel is tiny. The vast majority of the OS can be written in any language.
You'll certainly need to know C, yes, but just knowing C is nowhere near enough.
You might want to have a look at the Singularity project from Microsoft (also on Wikipedia):
Singularity is an experimental operating system being built by Microsoft Research since 2003. It is intended as a highly-dependable OS in which the kernel, device drivers, and applications are all written in managed code.
Only an extremely small part of this OS is actually written in C, and the rest is written in higher level languages (Sing#, an extension of C#). In the future I believe you can expect to see much more of this kind of thing becoming available.
I think its a pretty safe bet that serious (non experimental) OS development will remain in C (and assembly) for the forseeable future.
The proof I submit is Ada. It can get as bare-metal as C, provides better control over data placement, and has safer default behavior for just about everything (eg: array bounds checking). From the point of view of an OS developer, it is either equal or superior to C in any technical parameter you can think up. It has been available for over 20 years now (ok...reasonably-priced for perhaps only 15).
So if people were looking for a technically superior language to C, you should see OSes all over the place written in Ada instead right? What I actually see is one serious OS implemented in Ada. It is no longer supported in favor of a reimplementation in C.
The barriers to other languages in OS development are not and never have been technical. I don't see C's non-technical benifits going away any time soon, and nobody is ever going to overcome them by simply designing a better language.
Most definitely! You should also learn at least one assembly language/hardware architecture.
If it is kernel you are talking about, then you need to learn a language that will enable easy access to the underlying hardware, faster. I can only think of
- C language and
- Assembly
AFAIK, some parts of the boot-loader will be written in assembly, and from then on, C. There are many open-source easy-to-understand operating systems available, like for example the latest TOPPERS. Try to look into it.
I guess, as a OS-kernel developer, you will worry more about the ways to efficiently access underlying hardware (like processor and memory) rather than the choice of the language. I bet, most of the times, we will be tempted to use assembly
I've done extensive programming in both the Windows NT and Linux Kernel. And I can assure you that as long as these 2 OS's are around C will be used in the Kernel. I think it's a multitude of reasons, but the easiest answer is time. Like previous posters mentioned the amount of time it would take to rewrite the Kernel in a different language is not worth it. And it wouldn't just be porting the code. The kernel would need some serious design modifications. Personally I think C is the most suitable language for a Kernel. Being able to manage your open memory and dynamically allocate and free your own memory is crucial when you are working in the kernel. Especially if you are working with paged memory. The stack size you are allotted in Kernel mode is also generally smaller than user mode so again memory efficiency is crucial. C also allows programmers to build beautiful data structures that don't contain all the bloated overhead that managed languages have. In my opinion a struct can also be used just as effectively as an Object, but again without all the bloated overhead. Managed languages also need to be "managed." In the Kernel you don't have anything cleaning up your messes. Don't get me wrong, I love C# and I think the .NET framework is beautiful, but if you are in the kernel C is and will continue to be it.
C++ is supported for kernel mode development on Windows, but you can't use exceptions and RTTI easily. I believe that there is no reason to write code in C today, since the overhead of C++ is negligible (any tracing/debugging infrastructure will be far more costly than extra dereference for virtual function call). In fact most of the Windows DDK implement object oriented patterns with C, which is just inconvenient compared to C++.
If you decide to use C++ for kernel mode development, you will need to override the new operator to choose whether to allocate a class on pageable or non-pageable memory. Some nice macros might come handy there.
You should definitely be fluent in C.
As others have pointed out, there is no reason that an operating system has to be written in C, and there is a lot to be gained by using more sophisticated languages. But if you're going to work on operating systems in the real world (i.e., not in academia or a research lab) there are a couple of realities that you have to live with:
- Existing operating systems are huge, often many millions of lines of code, and are written in C or C-derivatives, such as Objective-C or C++.
- New operating systems take hundreds of engineer-years (and many calendar years) to reach and match the functionality and robustness of existing operating systems.
As a result, it's hard for me to see how and when the world will move away from C-based operating system kernels. Yes, it's technically possible. But the cost may be too high. If anything, the trend seems to be toward consolidation on a small number of OS families---Windows, Linux, and BSD---all C-based.
It would be interesting to know what research has been done, or what tools and techniques might be available to evolve an existing code-base (such as Linux) to a better language. I think this would be a much more viable approach than getting the world to adopt a completely new OS.
well, in the osdev community C is generally called the high-level language. And the more "low-level" language would be assembly (you are forced to use ASM in the start of your kernel, so you have to use ASM but you don't have to use C).
I point out the Oberon programming language and Oberon operating system from the author of the Pascal language, Niklaus Wirth. The Niklaus Wirth project has also a fan site.
If I understand the Андрей Николаевич Терехов correctly, the Ada has a benefit that memory access checks can be moved from CPU-hardware to compiler level, which reduces the amount of logic gates in the CPU, which in turn is beneficial from energy consumption point of view. The less logic gates a CPU needs, the more cores can be created from the same amount of logic gates. From that point of view CPU-s that are specifically tailored to a language, where the compiler replaces parts of hardware, have a fundamental advantage in terms of number of operations per Watt.
Too often, you can hear some telling : C language is synonym of speed and Ada, not. That's not true. Ada adds some checks that slow down execution. That's true but for debugging purpose or safety. They can hence, be deleted by configuration at compile-time. So, you can generate ADa programs without overhead. On the other hand, note that the gnu compiler translates Ada and C in the same intermediate code. As a result, you obtain the same executable code at the end. I read here that Ada can't be used for developing Drivers. That's false. Ada has the same capability as C language. More, it avoids many errors. You can see it exists a real-time operating system, MarteOS, totally written in Ada.
The main raison why Ada is not used for programming an OS kernel is that C language is the language used for Unix. It's a POSIX norm whom system call API is expressed with C prototypes. All the OS snippets are already written in C. And, C language represents 17 % of software developed in the world.
Finally, Ada is strict and many people dislike this. They prefer developing software with vulnerabilities and spending more time in debugging.
来源：https://stackoverflow.com/questions/861257/for-kernel-os-is-c-still-it