Eliminating Kernel Abstractions

And Allowing Them in More Proper Places, 2019 Edition


For this post, I am looking at the recent paper from HotOS 2019 "I/O Is Faster Than the CPU – Let’s Partition Resources and Eliminate (Most) OS Abstractions" by Pekka Enberg, Ashwin Rao, and Sasu Tarkoma from the University of Helsinki. This is a position paper that argues for a kernel design that eschews more traditional hardware abstractions and interfaces for a more direct approach driven by applications. They argue communication between software and I/O carries a heavy overhead for no application benefit due to interfaces that presume I/O is slower than the speed of the CPU. They then propose a particular system architecture without (most of) these abstractions.

But it is the hot take (and overall, albeit facetious, truth) we deserve!

This paper is an argument against abstraction which itself cites other forms of this argument dating back two and a half decades. There is a long history, here. It is written for systems people specifically, so I am going to tackle this topic by presenting this paper alongside a survey of the work that paved its way for all of the not-so-systemsy people out there. It is a fascinating topic full of a tremendous amount of misunderstanding and grandstanding, as you can see within the tone and subtext of the main paper itself (and its venue, HotOS, known for its... boldness.)

The place we start is, naturally, abstractions themselves. These are, essentially, the low-level interfaces that perform such obvious, now ubiquitious, things on the behalf of a programmer. Think "open a file", "send information on a network", etc. We need them for a variety of reasons, and their position within the system has been a long established argument within the field. I, myself, have written at length about the history of kernel/system abstractions, and this post is somewhat a follow-up with the new state-of-the-art. However, I will restate one thing here, and that is how important it is to ask not only what types of designs are better, but why outdated designs persist and how designs affect people.

Abstractions

Evaluation of Systems

Exokernel, Parakernel

Future

I have already co-written an essay about the error of

Tags

programming, programming/design

Comments

If you'd like to comment, just send me an email at wilkie@xomb.org or on either Twitter or via my Mastodon profile. I would love to hear from you! Any opinions, criticism, etc are welcome.

Donations

If you'd like to make a donation, I don't know what is best for that. Let me know.

Copyright

All content off of this domain, unless otherwise noted or linked from a different domain, is licensed as CC0