C++ or pure C for Linux kernel module, Linux device driver development. What to use?

paulsm4 · 08-21-2005, 07:03 PM

Hi, Igor007 -

Bottom line: if you want to write Linux kernel drivers, you really need to do it in 'C'.

Whether or not you *can* write a kernel driver in C++: I don't know. I doubt it. Whether or not you *should* write a kernel driver in C++: no, you shouldn't.

And if you want a good example of an OS written largely in C++: look at Windows 2000

Need I say more ;-)?

jstephens84 · 08-27-2005, 07:33 PM

Matir I think your program proves a big point. While the program may be small take to let say commercial size. I wonder what the results would be. You and your small app has helped me decide that I will study C instead of c++. Thank You.

Matir · 08-27-2005, 07:56 PM

No problem. I personally prefer C, but tried to make my pseudo-example as unbiased as possible. I would love for someone to provide a counter-example, even if it is NOT on runtime. Perhaps a counter-example of code readability, or stability. I don't think they'll find one, but I'm all for seeing one if there is one. We can all learn things.

gnashley · 08-28-2005, 08:24 AM

All kernel code is written in C -there are no c++ inluces in the kernel tree.

paulsm4 · 08-28-2005, 12:30 PM

In answer to the first question:

Q: "Can I write a kernel driver in C++?"),

the answer is :

A: Perhaps you *can* (if you're clever and/or determined enough), but you very definitely *shouldn't*.

In answer to your second (very different, completely independent!) question:

Q: "Can a C++ compiled binary be as efficient as it's C equivalent?"

A: "Quite possibly. But that's completely missing the point."

The question of "C" vs. "C++" (or, for that matter, C vs Perl or Visual Basic or anything else imaginable) is really "what's the best tool for the project"???

There is seldom any "right" answer, and how gosh darn small or fast the resulting binary compiles to is usually the *least* of your concerns. How closely the language maps to the problem domain is usually much more important. How robust and maintainable you can design the implementation is usually *vastly* more important. And, frankly, that's an area where C++ shines.

So no, C++ is not an appropriate choice for a kernel driver.

And yes, C++ might well be an appropriate choice for any library (e.g. programmer's API) or application (e.g. configuration program) that makes *use* of your kernel driver.

Kernel drivers are a "system thing", applications and application libraries are a "user thing", and C++ is more appropriate for the latter than the former.

IMHO.

Igor007 · 09-01-2005, 05:03 AM

paulsm4

MS Win OSes are not so bad.
Ofcourse the are less secure than Linux
But they are reliable and friendly enough
Espec. Win2003 Server

schneidz · 09-01-2005, 02:23 PM

matir's report is significant because the bigger the binary; the more machine-level instructions the processor has to execute.

from my engineering background i can appreciate the reduction in the number of assembly opcodes (and by relation the reduced machine hex codes).

i've taken courses in microprocessors and our major emphasis was reducing instructions to boost performance.

through my previous analysis i conclude through single-statment 'hello-world' programs, 'c' would be about 5 times more efficient than 'c++' in the amount of machine code generated.

addy86 · 09-02-2005, 05:03 AM

Quote:

Originally posted by schneidz
through my previous analysis i conclude through single-statment 'hello-world' programs, 'c' would be about 5 times more efficient than 'c++' in the amount of machine code generated.

That's like looking at an apple and concluding that all apples are red (but in fact they aren't), or using Windows for 30 minutes without crashing it and concluding that it's stable and secure (but it isn't).
Hello World is barely representativ.

schneidz · 09-02-2005, 10:57 AM

i think it can give a metric on what to expect on more robust testing (matir's testing).

what hello-world did for me was allow me to speculate on the probability of which is more efficient. much like not all apples are red but most are (probably about 90%). and windoze isn't always stable and secure but it mostly is (insert subjective opinion ----> here).

as a scientist we all test out speculations and then generate theories to be proved or disproved in postulations.

now that we have a basis for a baseline speculation, we should continue the thread by referencing in/formal reports that may bring us closer to a principle.

addy's post is correct because probably not all c++ code will be larger than comparable c code. (although there is more overhead with a fully object/class designed infrastructure).

can someone provide examples where c++ will be faster than c?

Matir · 09-02-2005, 11:20 AM

Quote:

Originally posted by schneidz

can someone provide examples where c++ will be faster than c?

Yeah, I was the guy with the original study, so my opinion may seem somewhat tainted, but here's my input as a Computer Science major:
C++ was never designed to be faster than C. It was designed to support classes, function and operator overloading, better type promotions, and other features.

paulsm4 · 09-02-2005, 11:57 AM

1. In general, C++ will be - at BEST - "as fast as" C.

2. One possible exception is using the C++ "inline" construct: the in-lined C++ code might well run faster than the most optimally-coded C equivalent.

3. Which, by the way, is a good example of why "fewer opcodes" is not always directly proportional to "faster execution". Often times *more* code results in *faster execution*. E.g. "loop unrolling".

4. The key point I've been struggling to make is that pure "code efficiency" (be it "code size" or "execution speed") is (I would strongly argue) a relatively *minor* consideration.

Whether C or C++ is the more appropriate tool for the job is *NOT* - repeat *NOT* - a question of whether one produces "tighter code" than the other.

5. And that brings me back to your original question, about using C++ in a kernel driver.

Yes, C++ would be a wonderful tool for the API libraries or utility programs that you might supply *with* your custom driver.

And no, 'C' is the *only* appropropriate tool for writing the kernel driver itself. Period.

6. Final notes:
a) If you're interested in investiging code performance issues, here are some great benchmark programs to play with:

http://www.netlib.org/benchmark/

b) If you're interested in analyzing system performance, this is a great book:

- The Practical Performance Analyst, Neil J. Gunther
(I understand he has a new version that uses Perl tools)

c) And these books have some very good discussions about the
relative UNIMPORTANCE of "optimizing code" (to the exclusion of
other concerns):

- The Practice of Programming, Brian Kernighan

- Code Complete, Steve Connell

I appreciate your interest in the questions "Can C++ be made to run faster than C?" and "How valid are 'Hello world' samples?" Matir did a great job, and I encourage you to look at the benchmarks I mentioned above.

But can we all agree that C++ is *not* a good tool for writing kernel drivers, and move on to another topic????

IMHO .. PSM

lowpro2k3 · 09-02-2005, 11:58 AM

Quote:

Originally posted by Matir
Yeah, I was the guy with the original study, so my opinion may seem somewhat tainted, but here's my input as a Computer Science major:
C++ was never designed to be faster than C. It was designed to support classes, function and operator overloading, better type promotions, and other features.

I agree, but I think its definately possible to write C++ code that is just as fast as C code. It all depends on the programmer and their knowledge of the two languages.

I don't think this first C++ program would be any slower or eat any more memory than this second C program, although I don't have time to test it at the moment (I'm in Windows, I'll try to benchmark later). Actually looking at the code I'm not too sure, the C one could be slightly faster. Again I'll try to benchmark later using the same tests used earlier in this thread. I should be home later tonite, in about 12 hours or so.

Code:

#include <iostream>
#include <cstring>
using namespace std;

// C++
class PrintC_String
{
  private:
    char * strptr_;
  public:
    PrintC_String()
    {
        strptr_ = new char[strlen(s) + 1];
        strcpy(strptr_, s);
    }
    void Print() { cout << strptr_ << "\n"; }
};

int main()
{
    PrintC_String s("Hello World");
    s.Print();
}

Code:

#include <stdio.h>
#include <string.h>

/* C */
void Print(const char* s)
{
    printf("%s\n", s);
}

int main()
{
    char* s = "Hello World";
    Print(s);
}

edit: This is not a good example of C++ code that is "just as fast" as C code. If I wanted to do that I would write C code and compile with a C++ compiler. Technically almost all C code is also C++ code. I wanted to use a simple example of C++ that used classes and a simple example of C code that used a function.

lmenten · 04-27-2007, 08:00 AM

The click router project at MIT was done in C++ for Linux. I have used the netlab.ru.is patches. Sweet. Works like a charm. My module is a stateful firewall and IDS/IPS written in C++. It has been used in VxWorks, pSOS, various flavors of Win, Linux, and under a real-time executive.

It is rather strange that embedded OS provide goods support for C++ but the Linux kernel does not.

Religion.

amitsharma91 · 08-20-2008, 03:10 AM

[QUOTE=Matir;1812389]Again, prove your point please. I would leave to see such a demonstration.[/QUOTHi FOlks

Hi Folks

I do not know, can i use C++ in Linux kernel with ARM , can some one help me , where i can get such stuff , and if i want to to do some porting where i should start.

ta0kira · 08-20-2008, 02:26 PM

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