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

[mag at intron.ac]

Dag-Erling  [iso-8859-1] Sm  grav wrote:

> mag at intron.ac writes:
>> But "-ffreestanding" doesn't work with C++.
> 
> While the C++ standard does define hosted and freestanding
> implementations, its definition is different from (and less useful
> than) that in the C standard.  For instance, the C++ standard requires
> the existence of abort(), atexit() and exit() even in a freestanding
> implementation.
> 
> Basically, one cannot indiscriminately use the same compiler flags for
> C and C++, because they are very different languages - far more
> different than they seem on the surface.  Modern C++ is very poorly
> suited for low-level code.

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.

We can judge whether a C++ feature can or cannot be imported into FreeBSD
kernel by assemble code generated by GNU CC.

For example, I think C++ exception handling is really poorly suited for
low-level code.

> 
>> According to above explanation, "-fno-builtin" is a subset of
>> "-ffreestanding" and it's enough for kernel.
> 
> No, it isn't.  I think you would do wisely to acquire a little more
> knowledge of and experience with C, C++ and kernel programming before
> you pursue this topic any further.
> 
> Most importantly, we already have an working object model in the
> FreeBSD kernel, with classes, inheritance, and all that jazz,
> implemented partly in C and partly in a custom IDL which is translated
> into C by src/sys/tools/makeobjops.awk.

Is the "object model" described in FreeBSD Architecture Handbook?
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/kernel-objects.html)

But the "object model" is still obscure to understand no matter how many
people all over the world master C++. What's more, can the "object model"
function really as OpenDarwin's IOKit class model?
(http://developer.apple.com/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/HelperClassesChart/chapter_12_section_1.html)

Now, OpenDarwin has owned a C++-based kernel object model. But why
cannot FreeBSD?

> 
> DES
> -- 
> Dag-Erling Sm  grav - des at des.no
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"



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.

But how difficult to write a device driver for FreeBSD? We have only
incomplete FreeBSD documents, and we must search FreeBSD source code
that probably has little relationship to the hardware device. If still
confused, we must search Google and submit a question in mailing lists
just like an ignorant pupil.

A really terrible style of FreeBSD device driver is REPEATING so many
codes similar to other device drivers.

Please look at files in /sys/dev/usb/. Why do so many USB device
drivers repeat:

   err = usbd_device2interface_handle( ... );
...
   for( ... ) {
...
     ed = usbd_interface2endpoint_descriptor( ... );
...
}

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.

Many USB/PCI driver need only override a member function like
"OnUSBMatch()" and "OnPCIProbe()" to identify a deivce by
Vendor/Product ID.

After matching, in many device drivers, a default member function
of base class like "OnUSBAttach()" or "OnPCIAttach()" can do attaching
operations in the most common way. Most of driver writes needn't override
default "OnXXXAttach()", and they can indicate its own IRQ, I/O address,
USB bulk in/out pipe by some member variables like "m_nIRQ", "m_nIOAddr",
"m_nUSBBulkIn" and "m_nUSBBulkOut", inherited from base class.

Userland program may call read() and write() while device driver may
simply submit/obtain a packet or a stream section to/from special member
functions without concerning buffering or not, O_NONBLOCK or not,
O_ASYNC or not.

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. At that time, FreeBSD can win
support from hardware manufacturers more easily.

You can LOOK DOWN UPON me again and again. But is it really your patent,
a FreeBSD security team member's patent: you know what FreeBSD kernel
and C++ is, but I am too BRAINLESS to understand FreeBSD kernel and C++?

------------------------------------------------------------------------
                                                From Beijing, China