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

[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.

> 
>> Well, you can LOOK DOWN UPON me, but I believe you cannot throw doubt on
>> FreeBSD's actuality: so weak USB support (kernel crash easier than many
>> other OSs that we laughed at and that we are laughing at), so weak PCI
>> device support.
> 
> Talking of USB, have you ever used a USB 2.0 Hi-Speed hub (single TT)
> with Linux and plugged TWO devices into it and see Linux fail to talk to
> the device you plugged in later? No? If so, you have zero clue how bad
> USB support can get. And that's not the only problem Linux USB has had
> or still has.

Actually, what I would talk about is Microsoft Windows 2000/XP. We should
ignore Microsoft's superiority just because we love FreeBSD.

> 
>> Please look at files in /sys/pci/ and /sys/dev/*/. Why do so many PCI
>> device drivers repeat:
>> 
>>    pci_read_config( ... )
>> ...
>>    sc->vr_res = bus_alloc_resource_any( ... );
>> ...
>>    sc->vr_irq = bus_alloc_resource_any( ... );
>> ...
>> 
>> Is this kind of awful writing just of FreeBSD's style?
>> 
>> In contrast, with C++, we can avoid many code repeating among device
>> drivers.
> 
> How would C++ avoid such? Generic programming, RTTI support and such
> stuff requires an awful lot of compile-time code generation and runtime
> library support.
> 

Why would people write Windows application with rather MFC/ATL/.NET
Framework than direct Windows API?
Why is gtkmm created for GTK+?
Would you write a X11 application with original X11 API, without QT or
other X11 toolkits?

Good packages for various APIs are much easier to learn/debug than those
original APIs.


>> If we would have constructed an object model in C++, a programmer who
>> master Microsoft MFC, Darwin I/O Kit could easily write a device drive
>> with the device's hardware data sheet.
> 
> And errata, and talking to the device happens in C-like programming
> anyways...
> 
> -- 
> Matthias Andree
------------------------------------------------------------------------
                                                From Beijing, China