Re: Compiling C++ kernel module + Makefile

[Bart Samwel]

Richard B. Johnson wrote:
> > > If somebody actually got a module, written in C++, to compile and
> > > work on linux-2.4.nn, as you state, it works only by fiat, i.e., was
> > > declared to work. There is no C++ runtime support in the kernel for
> > > C++. Are you sure this is a module and not an application? Many
> > > network processes (daemons) are applications and they don't require
> > > any knowledge of kernel internals except what's provided by the
> > > normal C/C++ include-files.
> >
> > Rest assured, ;) this is definitely a module. It includes a kernel patch that
> > makes it possible to include a lot of the kernel headers into C++, stuff like
> > changing asm :: to asm : : (note the space, :: is an operator in C++) and
> > renaming "struct namespace" to something containing less C++ keywords. The
> > module also includes rudimentary C++ runtime support code, so that the C++
> > code will run inside the kernel. I'm afraid that the task of compiling it for
> > 2.6 is going to be pretty tough -- the kernel needs loads of patches to make
> > it work within a C++ extern "C" clause, and it probably completely different
> > patches from those needed by 2.4. Getting the build system to work is the
> > least of the concerns.
>
> I can't imagine why anybody would even attempt to write a kernel
> module in C++. Next thing it'll be Visual BASIC, then Java. The
> kernel is written in C and assembly. The tools are provided. It
> can only be arrogance because this whole C v.s. C++ thing was
> hashed-over many times. Somebody apparently wrote something to
> "prove" that it can be done. I'd suggest that you spend some
> time converting it to C if you need that "module". The conversion
> will surely take less time than going through the kernel headers
> looking for "::".

Just to make this clear: I'm not the original poster, so I'm not the one 
who is to be helped. I just happened to know the module, and I'd thought 
I'd give you a quick answer because I knew it. :)

Now, let me try to add a bit of nuance to your suggested solution. Try 
porting 100s of C++ files (yes, it's that large) making heavy use of 
inheritance etc. to C. Then try to make a bit of C code usable as extern 
"C" in C++. Extern "C" was actually meant to be able to grok most C 
code, while C++ wasn't meant to be easily portable to C. So, for any 
moderately large module that uses any C++ features at all, it's probably 
easier to make small syntactic changes to the kernel than to port the 
module to C (which would amount to a full rewrite).

I'll give you a bit of background about the specific situation. I'm not 
involved with the project, so I don't know all the details, but I do 
know the code and have worked on a "competing" system (as far as 
research systems compete). The choice for C++ for this project is really 
the most obvious choice, as the model is very OO. The module implements 
a router model that is configured as "clickable modules", i.e., very 
small elements with input and output ports and a bit of state that are 
connected to each other through small interfaces. Their element 
implementations are arranged hierarchically (as in C++ class hierarchies).

I'm not familiar with the exact history of the project, but I expect 
that they decided to do C++ because the model they try to express is 
best modeled using C++. This design decision can be debated, because it 
is perfectly feasible (albeit with a lot more work) to implement an OO 
model in C. In fact, I have helped to implement a similar framework (the 
OKE CORRAL) which was written completely in C. But, the fact of the 
matter is, this useful (but huge) kernel module is there now (and it has 
been here since the early 2.2 kernels), and it was not written just to 
"prove" that it could be done, but because C++ seemed at the time to be 
the best language for the job. The start of this project may very well 
predate the many times that this was hashed-over on the LKML 
(disclaimer: I wasn't there, so I don't know). You refer to "what can 
only be" the arrogance of the writers, yet continue by claiming:

> I'd suggest that you spend some time converting it to C if you need
> that "module".

and

> The conversion will surely take less time than going through the
> kernel headers looking for "::".

Excuse me, but before calling somebody else arrogant, I would suggest 
that you might want check whether you're not calling the kettle black. 
It's not a sign of modesty when you assume without a trace of doubt that 
a module (that happened to have been developed over the course of four 
years by a team of people at MIT) is just a "\"module\"" and that it 
will take less time to port it to C than to make the kernel headers 
parse in a C++ extern "C" clause. In addition, imagine how you would 
feel if somebody referred to your work as a "\"module\""! The fact that 
you "can't imagine why anybody would even attempt to write a kernel 
module in C++" may just as well be due to a lack of imagination on your 
side, but in your statement I detect no trace of a doubt. And _yes_ you 
may very well be right about their initial decision being stupid (and 
you might not be -- I don't know), and _yes_ you are probably right 
about the whole thing being hashed-over many times (I don't know -- I 
wasn't there), and _yes_ there are people out there who would do 
anything just to prove they can do something others think is impossible 
or just filthy. So, yes, there _may_ be a point to what you're saying. 
_May_. I'm not saying you're wrong, and I'm not saying you're right. 
What I'm saying is that simply assuming that any C++ module is nothing 
more than a few lines of (de)glorified C and accusing the writers of 
being arrogant just because they wrote a kernel module in C++ is, in my 
opinion, jumping to conclusions based on 
technical-preference-turned-prejudice (at least, that's how it seems), 
and it's not very polite either.

Unfortunately, this is how flame wars get started (as can be seen by the 
slightly agitated tone this message has taken, sorry about that! :) ). 
Just to make this clear to everyone: I'm not trying to instigate a flame 
war here about C vs. C++, as I don't really have an opinion on that 
subject. This posting has to do with my preferences w.r.t. personal 
style, and nothing with my technical preferences.

-- Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/