LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
LinkBack Search this Thread
Old 08-20-2008, 10:50 PM   #31
amitsharma91
LQ Newbie
 
Registered: Oct 2005
Posts: 4

Rep: Reputation: 0
ARM C++ compiler


Quote:
Originally Posted by ta0kira View Post
I think the real problems with C++ kernel code are compiler-determined dependencies. Even without using a single #include, you can still incur dependencies when using C++. C++ generally requires some sort of entry and exit code, which g++ automatically links into executables and forces into init and fini in shared libraries. You'd be wasting your time to use static non-POD objects because it requires both initialization and destruction routines.

Most non-trivial kernel code requires dynamic allocation, or the kernel will provide the required memory in certain cases (such as ciphers,) which would require the use of in-place new with C++, which incurs a run-time dependency. As far as I know, the global new is also a run-time routine, though possibly-statically linked in by g++. In both cases you'd have to manually construct your structures, which is unreliable at best even without anything associated with the word "virtual."
ta0kira
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
 
Old 08-20-2008, 11:47 PM   #32
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
Quote:
Originally Posted by amitsharma91 View Post
Do you know any open sourec project has tried C++ for ARM. basically i am looking for linux kernel module compilation with g++
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

Last edited by ta0kira; 08-21-2008 at 12:28 AM.
 
Old 08-28-2008, 08:53 PM   #33
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 13

Rep: Reputation: 0
C++ is an appropriate language for kernel modules

Quote:
Originally Posted by ta0kira View Post
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?
 
Old 08-28-2008, 09:43 PM   #34
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
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

Last edited by ta0kira; 08-28-2008 at 09:44 PM.
 
Old 08-28-2008, 11:32 PM   #35
amitsharma91
LQ Newbie
 
Registered: Oct 2005
Posts: 4

Rep: Reputation: 0
Quote:
Originally Posted by lmenten View Post
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?


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
 
Old 08-29-2008, 08:38 AM   #36
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 13

Rep: Reputation: 0
Quote:
Originally Posted by ta0kira View Post
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
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.
 
Old 08-30-2008, 06:38 PM   #37
jiml8
Senior Member
 
Registered: Sep 2003
Posts: 3,171

Rep: Reputation: 114Reputation: 114
Quote:
Originally Posted by lmenten View Post
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.
 
Old 08-30-2008, 07:54 PM   #38
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
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
 
Old 08-31-2008, 01:39 PM   #39
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 13

Rep: Reputation: 0
Quote:
Originally Posted by ta0kira View Post
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.
 
Old 09-01-2008, 01:53 PM   #40
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
Good points.
ta0kira
 
Old 09-02-2008, 08:58 AM   #41
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,049

Rep: Reputation: 953Reputation: 953Reputation: 953Reputation: 953Reputation: 953Reputation: 953Reputation: 953Reputation: 953
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.)

Last edited by sundialsvcs; 09-02-2008 at 09:00 AM.
 
Old 09-03-2008, 09:45 AM   #42
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 13

Rep: Reputation: 0
Quote:
Originally Posted by sundialsvcs View Post
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 ; )

Last edited by lmenten; 09-03-2008 at 11:42 AM. Reason: Additional points
 
Old 09-03-2008, 11:31 AM   #43
paulsm4
Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
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 :-)
 
Old 09-03-2008, 11:44 AM   #44
lmenten
LQ Newbie
 
Registered: Apr 2007
Posts: 13

Rep: Reputation: 0
Quote:
Originally Posted by paulsm4 View Post
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

Last edited by lmenten; 09-03-2008 at 12:05 PM. Reason: Resist temptation.
 
Old 09-03-2008, 06:53 PM   #45
paulsm4
Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
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 ;-)

Last edited by paulsm4; 09-03-2008 at 07:03 PM.
 
  


Reply

Tags
arm, c++, compile, fine, kernel, linux, modules


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Linux kernel development vwal_13 Programming 3 03-09-2005 02:27 AM
Linux Device Driver Development aslv Linux - Certification 0 09-27-2004 08:42 AM
Linux Kernel Development impact on Slackware carboncopy Slackware 5 07-28-2004 03:43 PM
Touch screen driver development for Linux peso Linux - Software 1 02-02-2004 12:15 PM
Lexmark Released A Linux Driver Development Kit FearPasion710 Linux - Software 0 09-09-2003 06:18 PM


All times are GMT -5. The time now is 08:45 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration