I remember reading this years ago. It eventually gets into why the Linux kernel isn't written in C++, but the beginning of the discussion starts with an innoce

I remember reading this years ago. It eventually gets into why the Linux kernel isn't written in C++, but the beginning of the discussion starts with an innocent question about how to port a legacy kernel module that was written in C++ for 2.4 and no longer works with 2.6. The OP is roundly criticized for even considering writing a kernel module in C++. The authors of the module had to patch the Linux kernel heavily to make the headers compile as C++, and of course the patches for 2.4 don't all work for 2.6. I can agree that if you patch the crap out of an open source project, be it the kernel or just a library, to make it work with your own code, then you get what you deserve when it gets out of sync with the upstream version and no longer is compatible. How could it be otherwise? But as an experienced C++ hacker I disagree with the argument the C hackers made in the discussion that "you just can't use C++ there, you must use C" (to paraphrase). The problem isn't that they chose the "wrong" language, it's just that they interfaced the C++ code with the C (kernel) code incorrectly. The Right Way would be to simply write a compatibility layer in C that calls functions in the C++ code. And the C++ code could in turn call back to C functions in the compatibility layer when they need to interface with some kernel data structure. Although performance is listed as an issue, they specifically say that their module gets its performance benefit by not having to copy packet data to user space. They would still get this benefit, even if they had the minuscule extra time it takes to make a call through a C/C++ compatibility layer.