Prolog For years I've advocated that the FreeBSD Core team should write down a roadmap for the project for the benefit of elements of the community. People get hung up on the word roadmap, and that this is a volunteer effort. This document represents my response to that. It's also, sadly, a bit src focused in what it proposes, though many of the ideas can generalize across the project (and a real work product from core would have that balance) Main Theme This year's main theme is recruitment. The project's aging developer demographic strongly suggests that we need to focus on bringing new people into the project. Recruitment drives three areas of change: Technical, Management and Social. Technical FreeBSD is behind in a number of areas that's visibily hampering new people trying it out. While the project shines brightest in VMs, cloud, jails, storage and networking, there are a few areas that represent a barrier to entry to using the project as your daily driver. Wireless

Often times we need to do things to a commit after the fact. relnotes: yes was the first thing we discovered, and worked around that problem with a RELNOTES file. 'MFC After' also suffers from this problem. This proposal assumes that we're enforcing the git trailer rule. Namely that all our metadata is dash separated, not space separated. This proposal lays out a standard that our tooling will use and enforce. Notes will be added to commits in the source of truth FreeBSD repo. These notes are not pushed to github, so people wishing to use this tooling will need to add pulling of notes with fetch = +refs/notes/*:refs/notes/* in their .git/config. Start managing notes on commits The basic proposal is to move some of the metadata that we current put in-line in the commit to notes (though there's not a lot of harm allowing some of this inline, some things are impossible like MFC-With).

Where? Loader will create a firmware_path env var. This sill be created the same as module_path and will nomonially default to /boot/kernel/firmware;/boot/firmware based on where the loader is snagging the kernel from. Some firmware is tightly coupled to the driver. It will remain in the kernel build process, and install into $KODIR/firmware (/boot/kernel/firmware by default). Some firmware is loosely couple to the driver where the driver version generally doesn't matter. This firmware will go into /boot/firmware. This firmware will be moved into the buildworld side of the house, or out to ports. The packages from these ports should be in the install media if the device is a network or storage driver (or some other driver needed to install the system). Firmware that's part of the world build will live in share/firmware and will install to /boot/firmware or subdirectories of that. There's some firmware shared between multiple drivers, and that will wind up here (or as a pkg). Having it here would allow for pkgbase to slice and dice small. Some firmware will wind up in subdirectories, since that's how other OSes do it. Changes

It's time to eliminate the union ccb from the CAM API. This document describes the API changes, how we'll do it in a mostly KBI compatible way, and how we'll manage the cut-over. Problem statement There's places in the code that do unsafe things like pass a subset of a cam ccb, usually on the stack, into a call chain that shuffles it around as a union *ccb. This can be dangerout because only a subset of the union is valid in some cases. This is a historical practice that evolved when this sort of API was the best way to handle subclassing. Since then, the FreeBSD kernel has shifted paradigms abit. We now pass around the 'base class' rather than some super-set class that this union represents. It would also be nice to have some way to check the casting to make sure that the right function is set in the ccb header for the desired target cast item (with no checking for casts to ccb_hdr and the union if it still remains). In C, checks like this would need to go through a macro, which gets a bit ugly and verbose (one of the unsettled items at present). Proposed Changes Here's the changes that I think we need to make. Each one will be discussed in a subsection. We can use this list to prioritize the work and design a backwards compatible solution