The libkern C++ Runtime

https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/WritingDeviceDriver/CPluPlusRuntime/CPlusPlusRuntime.html

by ingve • 8 years ago

80 47 8 years ago

developer.apple.com

tzahola• 8 years ago

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• 8 years ago

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.

1over1372• 8 years ago

How many USB<->serial adaptors are there out there? Since 10.9 (IIRC), they've included their own FTDI driver.

I sure hope you're right though. It hasn't happened yet thankfully!

w0de0• 8 years ago

Exactly right. Often for devices, but also for software (usually enterprise). Here is a list of kernal extensions compiled by the macadmins community: https://docs.google.com/spreadsheets/d/1IWrbE8xiau4rU2mtXYji...

mattbauer2• 8 years ago

I think kernel modules will go away at some point. Having no third party Kexts would increase the security of the OS for in use systems. That's a nice way of saying not all third-party Kexts are created equal.

I could see an argument where moving existing hardware Kexts to user space is easier because IOKit uses the libkern C++ Runtime. The OO design of IOKit may lend itself very nicely to the driver approach BarrelFish takes (http://www.barrelfish.org). The real hard one to move to user space would be third-party filesystems. That's mainly because of dated VFS architecture used in *NIX systems. I could see Apple completely moving away from that at a future point too.

wichert• 8 years ago

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/

1over1372• 8 years ago

You can still fiddle with macOS. Though it's getting harder, with SIP and whatnot.

Still, disturbing that the URL includes "archive".

OTOH, they recently open sourced the iOS flip side of what's open on macOS. So who knows.

saagarjha3• 8 years ago

You can load kernel extensions with SIP enabled: the extension just needs to be “soft-approved” (i.e. you need to be in the developer program and explain why you need a kernel extension to Apple; no stringent requirements like the App Store review process obviously). With SIP disabled you can load extensions that have not gone through this process.

saagarjha3• 8 years ago

The UIKit on macOS API is supposed to be coming to developers next year. I don’t see ARM Macs or the deprecation of an API like this with no warning happening by then.

scruffyherder2• 8 years ago

It's what they did with the release of OS X 10.0, when they dumped the Objective C runtime/DriverKit for the C++ runtime/IOKit.

I mean, who needs old existing drivers anyways on a new platform?

mattbauer2• 8 years ago

It's not sneaky just because you're not looking. I have found the CoreOS group to be guarded in their responses to future directions but never sneaky. There have been multiple times where an API/design/etc change in a WWDC session didn't make sense. I would follow up in the labs and be told the reason is because X is happening in the future. Granted I'm not always told. In that case a diff of kernel sources between releases along with some years working in the XNU kernel is enough to figure it out. Sometimes you're just lucky and hint it in the actual session. For example the 2013 WWDC Session titled "What's New in Kext Development" (https://asciiwwdc.com/2013/sessions/707) leaked SIP well before it was officially announced. They key line was:

So in the future, we are going to tighten down access to the system hierarchy, the whole hierarchy down from /System and everything in there.

Another example of them sharing future plans was user space networking. I forgot what year it was but in the session they noted something about network kernel extensions (NKE) going away and to use Network Extensions instead. NKEs weren't the best but for Apple to send all the effort to recreate the 'same' thing in a new framework was odd. A visit to the labs and you were instantly told of the move to user space networking.

One last example. Apple ships in the default OS a number of third party mass storage kernel drivers. Take a look at /Library/Extensions on a new install. This ensure when you try to install that new OS or boot that new OS, you can see you're drives. Apple likely needs to work with those third-parties to make that happen.

I understand why it might appear sneaky but I don't think that's the case.

pjmlp3• 8 years ago

Yep, there a couple of interviews where Chris Lattner states that Objective-C 2.0 and later improvements where already a long term roadmap to what would eventually become Swift.

stefan_• 8 years ago

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

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

kjgkjhfkjf2• 8 years ago

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

nly• 8 years ago

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

kjgkjhfkjf2• 8 years ago

Hand-coding multiple versions of a function or class to accommodate various types would be just as bad in terms of code size, no? Plus it'd be tedious and error-prone to do this.

kllrnohj2• 8 years ago

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

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.

tcbawo• 8 years ago

It would probably expose too much of the implementation. Also, instantianted methods would live within the downstream libraries, making shared library linking fragile and un-upgradeable. Also, you could create your own specializations potentially circumventing safety/security features.

olliej2• 8 years ago

I suspect (never written anything substantial) that at least part of it relates to the age of a lot of xnu.

Basically think about the state of c++ and c++ compilers two decades ago. I wouldn’t be surprised if that factored into it.

As others have said codesize can also be an issue - it’s super easy to make templates produce insane amounts of code, especially in older compilers.

mrpippy2• 8 years ago

Exactly. OS X 10.0 shipped with GCC 2.95, it wasn’t uncommon at all to avoid templates and exceptions back then.

salgernon• 8 years ago

Compare with the NeXT "Driver Kit" library:

http://www.nextop.de/NeXTstep_3.3_Developer_Documentation/Op...

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

scruffyherder2• 8 years ago

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

mrpippy2• 8 years ago

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)

comesee2• 8 years ago

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.

saagarjha3• 8 years ago

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

comesee2• 8 years ago

I was talking about their custom runtime system that provides them type information, as well as generic container types and other features.

frabert3• 8 years ago

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

gigatexal• 8 years ago

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

BlackFingolfin• 8 years ago

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

pjmlp3• 8 years ago

Stronger type safety, fewer implicit conversions.

The libkern C++ Runtime

Related Stories