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

Object-oriented design patterns in the kernel, part 1

Posted Jun 3, 2011 14:46 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: Object-oriented design patterns in the kernel, part 1 by chad.netzer
Parent article: Object-oriented design patterns in the kernel, part 1

>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).

(Log in to post comments)

Object-oriented design patterns in the kernel, part 1

Posted Jun 3, 2011 17:49 UTC (Fri) by chad.netzer (✭ supporter ✭, #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.