Hi Man

Do you know any open sourec project has tried C++ for ARM. basically i am looking for linux kernel module compilation with g++

Thanks
Amit

No, sorry. Some version of Comeau might work since it merely digests C++ into C, but it costs money and Linux ARM for your specific distro is likely a port they don't have.

I personally think that a module complex enough to require C++ is a misappropriation of functionality. Kernel code should really be just enough to provide adequate resource control to user space, and the complex implementations of such resources should reside in user space programs.
ta0kira

I respectfully disagree. As do many highly proficient kernel module developers. Many kernel modules are quite large and could benefit from a language with better features for organization and expression.

Take a look through the kernel and you will see, an most large modules, various coding conventions being used force object-oriented concepts into a non-object-oriented language. Remember RATFOR? We once used coding conventions in FORTRAN to express structured programming concepts until we had such features in the language.

Remember that it was once the majority view that assembler was the only appropriate language for an OS kernel. In fact, many of us had peers who prided themselves in being able to create and toggle programs directly into memory with no assembler at all. Then along came Unix, written almost entirely in C (at Bell Labs, not Helsinki . You should have heard the uproar. Most kernel developers vigorously expressed their opposition.

Just as machine language was replaced by assembly language in kernel development, C will be replaced by a version of C++ and for the same reasons. And now any Linux kernel developers vigorously express their opposition.

And on and on it goes. Resistance to change, reluctant embrace, evangelism of the new status quo, resistance to change, ...

Do you detect the pattern here?

I'd "vigorously object" if they said the kernel was changing to Java or C#, but I only "casually object" to C++ because of the likelihood of dependencies arising from using a C++ compiler not designed for 100% stand-alone code. Sure, if g++ was designed to create 100% self-contained binaries then that would be something entirely different. I wouldn't even mind if they wrote the kernel in lisp. That might actually be fun.
ta0kira

hi

we decide to props this project in our company and hope approval will come and then we start , lets see how much we can do . hope for support for this job from group.very new in this type of job.

Thanks
amit

With the exception of exceptions, there is very little runtime code needed to support C++. There are several implementations of support for C++ exceptions in the Linux kernel too. The concept is appealing. The Linux kernel would be much more resilient if every module handled exceptions locally without panic-ing the kernel.

I would agree that it would be better if the kernel were more compact. The Linus decision to go with a huge monolithic kernel with a single memory space and no memory protection between kernel components was following in Microsoft footsteps. If the kernel were multi-layer, then we would have a more robust system and a much better platform for the construction of network elements such as routers, firewalls and IDS/IPS products. We'd also have a much better platform for the next generation of multi-player games.

The Windows NT kernel started out as a true microkernel - fully modular - but M$ moved away from that when they couldn't overcome the resulting performance problems.

The micro vs mono debate won't be solved here, and the hardware has come a long way since M$ made its decision. The linux kernel is robust enough, though it is intolerant of errors IN the kernel.

One can draw attention to an outwardly-ideal use of C++ in the kernel, which is replacement of all of those structs filled with function pointers and module specs with abstract classes. Sure, this seems like a great place to take advantage of C++, but it would require the use of vtables and possibly RTTI from within the kernel, and that sort of impedance doesn't belong at the core of a system. Everything at the kernel level transmutes and amplifies into everything the system as a whole does. I think the determining factors are C++'s dependence on constructors/destructors and its frequent multiple-dereference operations just to track down something as simple as a member function.
ta0kira

The overhead associated with vtables is exactly the same as that incurred by function pointers in structs and is much safer becuase of compile time checking. Furthermore, it is only incurred when polymorphism is employed. RTTI is totally optional. Since RTTI is not done often in the C-based kernel that issue is moot. When RTTI it is required it can be done with extreme efficiency, as demonstrated by the implementation from Reykjavik University. Constructors and destructors are not required and replace C init functions with the same efficiency. Inlining is much more practical with C++ than C and provide a substantial performance boost over what is possible/practical with C. C++ provides "references" which assure valid access to the referenced data or functions without the overhead of the repeated checking for invalid pointers that is required in C programs. Check the pointer when it is first passed as a reference and the compiler guarantees the integrity for subsequent calls. This provides a dramatic performance improvement over C. In short, there is substantial performance gain, as well as a reliability improvement, in using C++.

As pointed out, monolithic kernels are a few percentage points more efficient than the equivalent micro-kernel. All the more reason to use a language that provides excellent tools for compile-time checking. If you cannot afford to do much validation at run-time, you ought to use a language that is expressive enough to validate as much of the code at compile time as possible.

A C++ Linux kernel would kick the butt of the current C-based kernel.

Good points.
ta0kira

Kernel-level code does not run in "a normal application environment." Instead, it creates it. Which means that the kernel code, itself, must play by different rules.

This is one of the reasons why the amount of "kernel code" that actually gets built, in as many cases as possible, is as small as possible. Many subsystems rely upon userland code, running as "root" in a daemon dedicated to the task, to which the kernel communicates. These are privileged programs but they are also ordinary programs. The most-obvious example of such a program is init.

Languages like C++ are very-much designed to be userland languages. They're designed to run in "a normal application environment" and to make it very easy (sic...) for developers to write programs for such an environment. There is a large amount of application support (many megabytes of libraries...) upon which such languages rely. None of this exists in "kernel-land." (And, it doesn't belong there.)

C++ code is exactly the same size as the equivalent C code. If you would not otherwise use an object-oriented paradigm, you are free to use straight procedural code with exactly the same footprint but with the advantage of much more compile-time checking. Since the Linux kernel is huge and in a single shared memory space, more compile-time checking is badly needed. Microsoft's Singularity goes even further by requiring managed code throughout to achieve reliability in a monolithic kernel.

Apple's device driver framework (I/O Kit) uses inheritance and wrappers (C++) to achieve more reliable driver code with little or no run-time overhead. The key is an expressive language that enables more complete compile-time checking. In an OS, the most error-prone code are the device drivers. This is why NeXT and OS X have enhanced the reliability of kernel-resident device drivers through a Objective-C framework and C++-based framework, respectively.

C++ is the preeminent language for embedded systems programming and the most stable and secure OS kernels are written in C++. The Linux kernel is, unfortunately, not numbered among the most stable and secure kernels. C++ was designed to enable clearer expression of the programmer's intent while retaining the efficiency of assembler language and C. C++ does not rely upon libraries any more than C does and can leverage any APIs created for C. You must be thinking of Java ; )

Wow, lmenten! Where did you get that stuff from? I usually have to watch Fox News or something to get that much ill-informed nonsense :-)

1. V.R. Basili and B.T. Perricone, "Software Errors and Complexity: An Empirical Investigation," Comm. ACM, Jan. 1984, pp. 42-52.
2. T.J. Ostrand and E.J. Weyuker, The Distribution of Faults in a Large Industrial Software System, Proc. Int'l Symp. Software Testing and Analysis, ACM Press, 2002, pp. 55-64.
3. A. Chou et al., "An Empirical Study of Operating System Errors," Proc. 18th ACM Symp. Operating System Principles, ACM Press, 2001, pp. 73-88.
4. M. Swift, B. Bershad, and H. Levy, " Improving the Reliability of Commodity Operating Systems," ACM Trans. Computer Systems, vol. 23, 2005, pp. 77-110.
5. M. Swift et al., "Recovering Device Drivers," Proc. 6th Symp. Operating System Design and Implementation, ACM Press, 2003, pp. 1-16.
6. R.P. Goldberg, "Architecture of Virtual Machines," Proc. Workshop Virtual Computer Systems, ACM Press, 1973, pp. 74-112.
7. J. LeVasseur et al., "Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines," Proc. 6th Symp. Operating System Design and Implementation, 2004, pp. 17-30.
8. J. Liedtke, "On Microkernel Construction," Proc. 15th ACM Symp. Operating System Principles, ACM Press, 1995, pp. 237-250.
9. H. Hartig et al., "The Performance of Microkernel-Based Systems," Proc. 16th ACM Symp. Operating System Principles, ACM Press, 1997, pp. 66-77.
10. J.N. Herder et al., "Modular System Programming in MINIX 3," Usenix; http://www.usenix.org/publications/l...dfs/herder.pdf.

... and ...
ISO/IEC TR 18015:2006(E)
2006-02-15
Technical Report on C++ Performance

Oh yeah - I forgot about Basili and Perricone's discussion about the use of C++ device drivers for Mac OS X in the 1984 ACM article. Thanks for refreshing my memory on that one ;-)

Again - I think most of what you're saying is absurd. At least the parts that aren't simply false...

IMHO .. PSM

PS:
I agree with ta0kira - I'd be intrigued by a LISP kernel, too ;-)