kern/99979: Get Ready for Kernel Module in C++

[Attilio Rao]

2006/7/11, mag at intron.ac <mag at intron.ac>:
> Why do you all consider importing C++ code to FreeBSD kernel to be so
> complicated at the beginning?
>
> Matthias Andree wrote:
>
> > (please don't Cc me on list replies; chopping down the Cc list)
> >
> > On Tue, 11 Jul 2006, mag at intron.ac wrote:
> >
> >> Just as you said, C++ is more complicated than C. However, without
> >> C++ exception and other advanced features, it hasn't brought much
> >> complexity to C++ runtime library. Early C++ compiler even translates
> >> C++ code into C code before real compilation.
> >
> > But what's the point of C++ if it is mutilated below minimum standard
> > compliance levels so that you can no longer call it C++?
> >
> > This discussion has been through for other systems such as Linux long
> > ago, and it wasn't lack of manpower, but lack of technical feasibility,
> > or in other words, what was still useful for a kernel wasn't that much
> > different from C any more. C99 already adressed several concerns of C89,
> > and ISTR that FreeBSD kernels are C99 code these days.
> >
> >> We can judge whether a C++ feature can or cannot be imported into FreeBSD
> >> kernel by assemble code generated by GNU CC.
> >
> > Great, make the whole kernel depend on compiler internals.
> > Can you imagine a single vendor who'd have interest in hauling so many
> > dependencies into their software and handle all the support? I can't.
>
> Please complain about the portability of runtime library after reading
> codes in /usr/src/contrib/libstdc++/libsupc++/.
> Are they really so difficult to port?
>
> >
> > Write a C stub and put the rest into userspace where C++ works.
> >
> >> For example, I think C++ exception handling is really poorly suited for
> >> low-level code.
> >
> > Which chops off one of C++'s legs to stand on.
>
> Aside from the complexity of implementing C++ exception, in kernel, every
> exception must be carefully processed. A simple exception throw may lay
> memory leak and unfreed resource allocation. And outer exception catch
> is difficult to help inner exception.

Even if I have no proof-of-concepts (so maybe somebody can show that
this is not fair), if we have setjmp/longjmp in the kernel we can have
a correct exception handling mechanism without not great problems.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein