Date: Tue, 11 Jul 2006 22:45:52 +0800 From: mag@intron.ac To: des@des.no Cc: freebsd-hackers@freebsd.org, Matthias Andree <matthias.andree@gmx.de>, delphij@delphij.net, Julian Elischer <julian@elischer.org> Subject: Re: kern/99979: Get Ready for Kernel Module in C++ Message-ID: <1152629241.24779@origin.intron.ac> In-Reply-To: <868xn0z8w9.fsf@xps.des.no> References: <200607092136.k69LaNDX055391@www.freebsd.org> <84dead720607092015q7f1701abse143f3855c2aa95a@mail.gmail.com> <1152540567.99616@origin.intron.ac> <44B2AE69.4080703@elischer.org> <44B2D2DF.2000401@sh.cvut.cz> <86sll8zl9x.fsf@xps.des.no> <courier.44B35DBC.00003F75@intron.ac> <86fyh8zgw8.fsf@xps.des.no> <courier.44B37714.00004B4D@intron.ac> <868xn0z8w9.fsf@xps.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling [iso-8859-1] Sm grav wrote: > mag@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@des.no > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1152629241.24779>