Object-oriented design patterns in the kernel, part 1 [LWN.net]

Object-oriented design patterns in the kernel, part 1

Posted Jun 3, 2011 2:34 UTC (Fri) by chad.netzer (subscriber, #4257)
In reply to: Object-oriented design patterns in the kernel, part 1 by Cyberax
Parent article: Object-oriented design patterns in the kernel, part 1

> Kernel is not exactly monolithic as well.

Sure it is. Certainly in the classic sense of not having memory access isolation between all services, drivers, etc. The Linux kernel may be modular, and have some kernel threads, but it is "exactly monolithic" by the standard definition, is it not?

Thus, it isn't paranoia on the part of the developers to use a language that allows one to fairly easily see what memory accesses are occurring on a roughly line per line basis (such as C).

> Ah, and I've forgotten about another large C project switching to C++ (gcc)

That's interesting, because the gcc development seems so different from Linux's; things like the copyright assignment provisions may (or may not, I'm speculating) affect the contributor pool in a way that makes the transition more practical. In any case, compilers work at a different level, so that the memory access abstractions of C++ aren't so objectionable. In fact, I suspect hey have more data structures and inheritance possibilities that would benefit directly from it, and it's probably a good choice for them. But I don't think that necessarily translates into a reason for a kernel project to do the same.

In any case, while I disagree with daglwn's assertion that Linus was "flat out wrong" about C++, it's exciting to see projects that implement a kernel in a language like C++ (or D, or Go, etc.) to know how the language features influence design decisions and ease of implementation, to see if it really matters.

(Log in to post comments)

Object-oriented design patterns in the kernel, part 1

Posted Jun 3, 2011 14:46 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>Sure it is. Certainly in the classic sense of not having memory access isolation between all services, drivers, etc. The Linux kernel may be modular, and have some kernel threads, but it is "exactly monolithic" by the standard definition, is it not?

I don't mean 'monolithic' in the sense of 'monolithic vs. microkernels'. I meant it in the sense of 'one giant C file vs. modular code'.

Linux Kernel is divided into subsystems which are pretty independent: network layer doesn't really care about DRI, for example.

>In any case, while I disagree with daglwn's assertion that Linus was "flat out wrong" about C++, it's exciting to see projects that implement a kernel in a language like C++ (or D, or Go, etc.) to know how the language features influence design decisions and ease of implementation, to see if it really matters.

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

Object-oriented design patterns in the kernel, part 1

Posted Jun 3, 2011 17:49 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]

> I don't mean 'monolithic' in the sense of 'monolithic vs. microkernels'.

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.