
The libkern C++ Runtime - ingve
https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/WritingDeviceDriver/CPluPlusRuntime/CPlusPlusRuntime.html
======
salgernon
Compare with the NeXT "Driver Kit" library:

[http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/Op...](http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part3_DriverKit/Concepts/1_Overview/Overview.htmld/index.html)

Very similar layout, but it used Objective-C instead of C++.

------
stefan_

        #define super    IOService
        #define fBlastIForgot [..]
        OSMetaClassDeclareReservedUnused
        OSMetaClassDeclareReservedUsed
    

This is so much nicer than just function pointers, base members and
container_of!

------
kjgkjhfkjf
I wonder why they deemed templates to be "insufficient or not efficient enough
for a high-performance, multithreaded kernel".

~~~
nly
Probably code size. Any two template instantiations, even if they produce
identical machine code or in-memory representation, will generally be output
twice due to language requirements like needing distinct memory addresses and
linkage for things like functions, static data members, static locals, RTTI,
vtables etc.

Eliminating code bloat with templates requires careful judgment about where to
put type erasure and how to factor your code

~~~
kllrnohj
C++11 added extern templates which can easily solve the bloat problem. If a
template consistently has the same type like, say, std::vector<int>, you can
just extern it and tada they all share the same generated implementation (
[https://isocpp.org/wiki/faq/cpp11-language-
templates#extern-...](https://isocpp.org/wiki/faq/cpp11-language-
templates#extern-templates) )

So even if the linker fails to de-dupe, you're still able to manually fix it
pretty easily without giving up on templates entirely.

But libkern predates C++11, so decisions made by that team at that time are
largely obsolete and should be heavily re-evaluated rather than blindly
followed.

~~~
olliej
A lot of the xnu c++ dates back almost two decades (maybe more?), and abi
compatibility kind of screws in terms of changing decisions like this.

You can’t really just say “update to a newer version of the language” when you
have both API and ABI compatibility constraints.

For source you can deprecate APIs, etc so future versions would have an early
warning the source changes would be necessary.

But that doesn’t help shipping kexts, for that you need ABI stability, which
really puts the hammer on changing/updating the features that you use. Many of
the C++ features cause exciting binary compatibility problems, and make it
super easy to accidentally change the ABI :-/

~~~
kllrnohj
My point was just that anybody using C++ _now_ shouldn't treat language-
feature advice from 20+ years ago as anything particularly relevant. It's
outdated and obsolete and should be treated as such. Sure if you're working on
an obsolete codebase in bare-bones maintenance mode then you're kinda stuck,
but most of us aren't.

That aside yes, you totally can just update to a newer version of the
language. If you are trying to maintain C++ ABI stability then your life is
harder, yes, but it's no harder than it already is when you just upgrade
compilers or deal with people building with other compilers (and most everyone
ships C ABIs anyway to avoid this entire category of problems - extern "C"
still works great in C++17). But you are still completely free to use newer
features in the implementation itself which doesn't impact API or ABI
stability in the slightest.

------
scruffyherder
I was pretty sure it was because getting people to write drivers in Objective
C for DriverKit was never going to reach any mass appeal, so better make it
C++

[http://unix.superglobalmegacorp.com/cgi-
bin/cvsweb.cgi/objc/...](http://unix.superglobalmegacorp.com/cgi-
bin/cvsweb.cgi/objc/ChangeLog?rev=1.1.1.1;cvsroot=Darwin0)

~~~
mrpippy
Yep. Everyone writing drivers for Windows/Classic MacOS/UNIX was doing it in
C. And Apple wasn’t particularly confident that ObjC would appeal to even
application programmers (hence the Cocoa-Java push, and the never-finished
ObjC “modern” syntax)

------
gigatexal
They took out templates, inheritance, exceptions? What’s left to make it not
just C?

~~~
BlackFingolfin
Plenty: classes (including constructors/destructors, virtual methods, etc.),
operator overloading, patterns like RAII, ...

~~~
pjmlp
Stronger type safety, fewer implicit conversions.

~~~
masklinn
> fewer implicit conversions.

Surely C++ has way more implicit conversions than C, what with having all of
C's _and_ ctors defaulting to converting?

~~~
pjmlp
Only if developers are too lazy to use _explicit_.

I was referring to C implicit conversions that aren't valid in C++ code, like
_void_ __* to other pointer types.

------
tzahola
The good old times when Apple let devs fiddle with their OS.

These APIs are already deemphasized, so I wouldn’t be surprised if they were
to deprecate/remove them altogether when they release the ARM version of
macOS. They’ll probably do it with the update that introduces UIKit on macOS
(as Craig Federighi said on this year’s WWDC) to divert the attention. Sneaky
bastards, but their stuff still sucks the least ¯\\_(ツ)_/¯

~~~
X-Istence
Certain devices are still going to need loadable kernel modules to be
supported.

For example USB to Serial devices, or custom media devices, and more. I really
don't expect kernel modules to go away.

~~~
wichert
I found Serial[1] a while ago: a decent terminal application that does not
require any drivers / kernel modules to support USB-to-serial devices.

[1]
[https://www.decisivetactics.com/products/serial/](https://www.decisivetactics.com/products/serial/)

~~~
voltagex_
I wonder how that works?

~~~
pilif
macOS comes with very good USB support in user-space that works without any
drivers.

[https://developer.apple.com/documentation/iokit/iousbinterfa...](https://developer.apple.com/documentation/iokit/iousbinterfaceinterface190?language=objc)

------
comesee
Ideology disguised as logic. Basically NIH. Apple engineers could have made
C++ RTTI, and other other native features, suit their requirements. Instead
they created a bastardized dialect of C++ which requires new domain knowledge
to use effectively.

~~~
saagarjha
I believe the dialect of C++ that Apple uses for IOKit is based on a dialect
called Embedded C++, which was created an industry standard:
[https://en.wikipedia.org/wiki/Embedded_C%2B%2B](https://en.wikipedia.org/wiki/Embedded_C%2B%2B)

~~~
frabert
Banning the use of namespaces and templates for embedded programming seems
arbitrary at best, since they are both completely compile-time features

~~~
bnastic
IOKit predates anything resembling wide adoption of those C++ features.
Exceptions are a particularly thorny subject when mixed with multithreading
and (non-existent) memory model. And not to mention RTTI, which was always
just a patch job.

~~~
frabert
I think choosing to exclude exceptions is a totally fine decision, and I
actually think it's the right thing to do in embedded systems where you
_cant't_ afford to let an uncaught exception bubble up

