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?
相关问题
- Why should we check WIFEXITED after wait in order
- Linux kernel behaviour on heap overrun or stack ov
- Where is the standard kernel libraries to let kern
- Is there a difference between an ISR and an interr
- Trouble with SPIDEV, device tree and .dtbo name wi
相关文章
- How do I get to see DbgPrint output from my kernel
- What happens to dynamic allocated memory when call
- Is it possible to run 16 bit code in an operating
- How to arrange a Makefile to compile a kernel modu
- Tool to Debug Guest OS in Virtual Box
- How can the linux bottom halfs execute in interrup
- Linux Kernel Linked List
- How is copy paste possible?
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.
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.
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.
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.
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.
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:
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.