>Do we allow device drivers to be C++, but still use the core C kernel code? Or do we require the device drivers to be C, but redesign the core with C++? What subsystems would benefit *immediately* from being rewritten in C++? These are questions without obvious answers, imo.
Any real refactoring of Linux-sized codebases MUST be gradual. Hypothetically, I'd first clean up kernel source to allow C++ drivers, introduce kernel-side C++ library and then slowly convert subsystems to it.
Though by now it might not get us much benefit, I admit. A lot of kernel code is fairly conservative and rewriting it just for the sake of rewriting won't get us anything useful.
>I'd bet a kernel project that was started from scratch using C++, could probably *not* sustain the rate of development that Linux has seen, given the nature of it's contributor base. Those projects you mentioned all started in C++ (AFAIK), typically with a small focused team of programmers, all commercially funded (except LLVM, which had research funding initially), whereas Linux had an explosion of early volunteer contributors.
KDE started the same way - an explosion of contributors working on the same goal. By now it's comparable in size with the Linux kernel. Ditto for Haiku OS (though it can't compare with Linux).
At smaller scales, we're seeing addition of C++ to the Mesa project right now (new shader compiler and optimizer is written in C++) and it seems to be working out fine. Though they use it in C-with-classes fashion, mainly for the 'Visitor' pattern.