kern/99979: Get Ready for Kernel Module in C++
mag at intron.ac
mag at intron.ac
Tue Jul 11 17:41:01 UTC 2006
Joerg Sonnenberger wrote:
> On Tue, Jul 11, 2006 at 10:45:52PM +0800, 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.
> RTTI, allocation, exceptions and static allocators all add complexity
> for the runtime library. If you really want to use C++ for a kernel, you
> must likely want to use all of them as well.
>> For example, I think C++ exception handling is really poorly suited for
>> low-level code.
> Bullshit. With a proper implementation exceptions add no overhead as
> long an exception is not thrown in terms of speed. It does matter
> somewhat in terms of code (or better: data) size, but the very same
> information is useful to generate much better tracebacks as well.
> RTTI is highly useful for debugging and semi-optional consistent checks,
> which should not be neglected either. I don't care about the abuse of
> explicitly comparing object types etc., but the ability to decide what
> exactly a certain object is.
Aside from the complexity of C++ exception support, in FreeBSD
kernel, every exception must be carefully processed, simple
exception throw and catch may lay memory leak and resource non-freeing
inside kernel if the programmer fails to pay enough attention.
Even if C++ code is carefully written for FreeBSD kernel, outer
exception catch is so difficult to help deep inner exception.
>> 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?
> The kobj implementation has the same feature set as a lightweight C++,
> e.g. inheritance and virtual functions. That's basically what IOKit is
> using as well. It is not obscure, just a Domain Specific Language.
A domain specific language, C function pointer list, software
context and other independent kernel functions are obscure enough for
>> Now, OpenDarwin has owned a C++-based kernel object model. But why
>> cannot FreeBSD?
> Because the kernel is C and not many points to incrementally add C++
> have been made, which makes it a worthwhile goal.
> And if you want to complain about redundancy in drivers, carefully look
> for differences which often far outweight the common functionality.
If there's only small differences, there operations can be packed
into a function tunable by some arguments.
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
From Beijing, China
More information about the freebsd-hackers