Object-oriented design patterns in the kernel, part 1

Well, that's confusing then. The term already has meaning in kernel discussions, and you were responding to *my* usage of the term. But, ok.

The concerns I mentioned still apply for pretty independent codebases: if you intend to build the whole kernel with C++, you have do deal with all the legacy C code and interaction issues (function namespace, type incompabilities, etc.) so as you said it must be gradual. But, if it's gradual, you now have a complicated mixed build system and have to worry about how to interact across the C/C++ layers (since there is no agnostic "message passing" layer for the components, like a microkernel would have). It could be done, I'm sure, it just a matter of what is motivating it.

It might make sense if there already existed some well tested code bases that were worth integrating; let's say hypothetically that ZFS had been released as GPL years ago, but it's implementation was in C++. Then I could see dealing with the pain (or attempting it), rather than a rewrite.

> It doesn't look like that C vs. C++ matter much in kernel development (look at L4 kernel, for example).

Well, L4/Fiasco *is* a microkernel, with a well defined message passing ABI, built by a small team, and is *tiny*. But it demonstrates that design of the OS is the much bigger issue than language implementation for the most part. The language issue really matters more (imo) from a community and potential contributor perspective.