OS : The underlying overhead of computation, Antti Kantee

An operating system is a piece of code intended to help computer operators load punch cards -- hence "operating". The timesharing system was created to allow interactive shared access to the handful of computers which existed at the time. We will examine what is in the interactive punch card loader in 2017, what actually belongs in there, and why things are the way they are.

Speaker Bio

Antti Kantee has been a NetBSD committer since the 1900's and has managed to do many sorts of damage. He is probably best (or worst, depending on who you ask) known for his decade-long workhaul on rump kernels. Antti very recently moved to the Princeton area, so in case he appears particularly absent during his talk, he got lost on the way to the venue.

"Once again, I've done something no one asked for": New (and old!) C/C++ compilers for your next *BSD adventure: a tale of advocacy: and a sub-sub-subtitle to drum up intrigue, Brian Callahan

At NYCBSDCon 2007, a talk titled "BSD is Dying" took the world by storm. Two years later at DCBSDCon 2009, we got the follow-up "BSD is (Still) Dying." A year later, "BSD Needs Books" was presented at NYCBSDCon 2010, followed up with "BSD Breaking Barriers" at NYCBSDCon 2014.

These excellent presentations fall into what I call "BSD advocacy for everyone" talks. That is, talks that can get anyone excited about joining the *BSD community and fully bringing themselves and their skills and gifts to our little piece of human history. But the most recent of the talks above is a decade old at this point. What should a "BSD advocacy for everyone" talk look like in 2024? How ought we communicate the value of the software and ourselves to the broader world today?

Come with me on an exciting journey on how I wrangled the proprietary Oracle Developer Studio and Intel oneAPI DPC++/C++ compilers to run on FreeBSD and NetBSD and output native binaries for those operating systems. This journey is interesting to our question of "*BSD advocacy for everyone" by highlighting the power of the BSDs, the flexibility to undertake and excel at any task you might throw at them, and how many of the perceived problems those on the outside might feel "hold us back" are social, not technical, in nature, and how we can lead in turning the tide on outsiders' thinking in myriads of easy and small, large, and in-between ways.

Christos Margiolis: Arbitrary Instruction Tracing with DTrace

The talk will cover the high-level ideas behind kinst's implementation, that is, the mechanisms used to instrument arbitrary kernel instructions, the obstacles of architecture-dependent code parts, and how inline function tracing works. It will also include examples of how kinst is used, as well as when it's useful.

Christos Margiolis:

Dave Cottlehuber: Immutable FreeBSD

This talk will be generally suitable for anybody managing multiple FreeBSD systems, automating their lifecycle, and will show working code.

Dave Cottlehuber:

Encouraging SMEs to contribute to Development of BSD - TomSmyth - EuroBSDcon 2023.

Connecting volunteer developers to sources if funding.

Philipp Bühler gives a wonderful talk on 20+ Years of EuroBSDCon History.

Hiroki Sato: USB Debug Capability (DbC) Support on FreeBSD

USB Debug Capability (DbC) is a standardized functionality in Host Controller Interface of USB 2.x and 3.x. It is a hardware-level circuitry available as a hidden serial communication channel that can work even with no operating system support and is supposed to be an out-of-band access endpoint for debugging. When a kernel panic occurs, we cannot get debugger access on laptops or consumer-grade motherboards with no physical serial port. USB DbC can be used even in that situation and is greatly helpful for kernel development.

This talk covers the technical details of how DbC works, the implementation for FreeBSD, and how to use it.

Hiroki Sato:

Björn Gohla: A Haskell Binding for OpenBSD Pledge

The pledge system call on OpenBSD is a voluntary security mechanism, that a process can use to restrict the available kernel API. It is used throughout the OpenBSD base system and some ports, to guard against undiscovered exploits, following the defense in depth principle. System calls are aggregated into related groups called promises. It is considered good practice to discard a promise, i.e., access to any part of the kernel API, as soon as it is no longer needed.

Haskell is a lazy functional language with a powerful static type system. Side-effecting computations, notably IO, are clearly distinguished from pure computations in the type system. Effectful computations of the same kind can be sequenced using a sequencing operator, and this ensures control over the ordering of effects in the presence of lazy evaluation. Haskell also provides special syntax that makes effectful functional code look like familiar imperative code.

We will demonstrate a refinement of this approach to IO-effecting computations with type level information about pledge promises, and an appropriate sequencing operator, that causes static computation of the combined promises for sequenced actions and automatically inserts the correct pledge calls. This has no added runtime cost, apart from serializing the promise set and calling pledge.

Using this approach, we can guarantee that promises are always discarded at the earliest possible time, even in potentially large applications, assuming that the basic actions have been labeled correctly. We can also use type annotations to either let the compiler work for us and compute the required promise set for a given sequence, or else specify a promise set and be assured that a given sequence does not violate it.

We will provide the necessary background in Haskell and show some real world application code using this interface.

Björn Gohla:

He is a part-time user of OpenBSD and works as a Haskell engineer at Scrive.

Klemens Nanni: The OpenBSD installer

Also responsible for upgrades between development snapshots and proper releases, its goal is to provide an as effortless, streamlined and reliable user experience as possible, with sane defaults for the majority of use cases.

Tight integration into the build infrastructure, coordination with firmware, bootloaders and kernel features, but also help from a running system are crucial parts in this delecate machinary known as "the installer".

To keep up with new hardware, OpenBSD's design and features and common usage patterns, more seemingly innocuous aspects must be considered.

This talk shows what "the installer" is made of, explains how it works and demonstrates how recent efforts to improve it can look like.

Klemens Nanni:

Opening Session - Henning Brauer - EuroBSDcon 2023