LWN.net Logo

C++ ... iokit?

C++ ... iokit?

Posted Sep 23, 2007 23:25 UTC (Sun) by mattmelton (subscriber, #34842)
Parent article: Quotes of the week

imo, and I've seen it stated many times, Apple's IOKit trumps linux in driver development.

this is probably my 5th comment announcing linus' increasing irrelevance to the rest of the world, but it's comments like this - a reiteration of an older one i know - that showing he's not willing to adapt to the needs of the other type of user... the commercial developer.

Linux needs a native C++ runtime to allow an easier development cycle (linux-macos drivers!)... we're bitching we cant get drivers out on time, but we're not exactly helping the hw developers!

iirc, someone did write a cpp runtime and model for 2.4... shame it didn't catch on.


(Log in to post comments)

C++ ... iokit?

Posted Sep 24, 2007 20:55 UTC (Mon) by nix (subscriber, #2304) [Link]

Your terms are sufficiently vague as to make it unclear what you're
talking about (Linux *has* a native C++ runtime library, it's called
libstdc++).

However, if you're suggesting what I think you are, you seem to think that
adding the necessary magic to allow kernel drivers to be written in C++
will somehow magically both make `commercial developers' happy, and allow
a single driver to be used that will work with both Linux and MacOS X.

Both these assumptions are untrue.

Firstly, commercial developers mostly don't care about drivers. They're
writing applications: hardware support is way below anything they care
about. Some might care about one or two specialist pieces of hardware, and
writing a so-so driver for one piece of hardware, unless it's viciously
complex, is not terribly hard. Throwing C++ into the mix won't make it
easier.

Secondly, C++ is not magic compatibility sauce. Adding a C++ abstraction
layer to the kernel will have numerous costs --- of which the *smallest*
is the oft-quoted one that C++ does too much behind your back. Much more
significant is that C++ coding works best when everything is wrapped into
objects, which means that huge numbers of (mostly small) abstraction
layers would need to be written to wrap up the existing internal C
interfaces with a C++ facade, and all these layers would need to be
maintained --- yet the people who maintain the C code are mostly not C++
programmers, so wouldn't do it themselves. So the C++ layers would be
broken much of the time.

Thirdly, adding that C++ abstraction layer certainly won't help joint
Linux/MacOSX drivers get written. What you need there is an abstraction
layer to map between the Linux kernel and the (quite different) Darwin
kernel, and that is a *big* job. Feel free to try it: I predict you'll
fail. The kernels are too different and the Linux kernel at least is
changing way too fast to make this remotely practical. Even if it worked,
and even if the runtime overhead of this abstraction layer were nil (a
pipe-dream), such drivers would have the lowest common denominator
problem: they couldn't take advantage of anything Darwin or Linux could do
unless it was in both, which means they'd stick out like sore thumbs on
both OSes.

(And Linus is increasingly irrelevant? You *are* a troll, aren't you? A
troll subscriber, oh dear.)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds