2

I want to develop a new feature or change and existing program of the FreeBSD distribution, specifically the user space¹. To do so, I need to make changes to the FreeBSD code base and then compile and test them.²

Doing so on the tree in /usr/src and installing the result on the system seems like a bad idea, given that it requires you to run your development machine on CURRENT, to develop with root privileges and hoses your system if you make a mistake. I suppose there must be a better way and possibly a standard setup FreeBSD developers use.³

What is the recommended workflow to develop the FreeBSD code base?

¹ so considerations specific to kernel development aren't terribly important

² I'm familiar with the process to submit changes after I have developed them

³ I have previously read both the development handbook and the FreeBSD handbook chapter on building the source but neither seem to recommend a specific process.

fuz
  • 88,405
  • 25
  • 200
  • 352

2 Answers2

5

I am a src committer.

I often start with the lowest release that I intend to back port to (e.g., RELENG_11_3.

I would then do (before or after making changes):

   make buildworld

then deploy to a jail directory:

   make DESTDIR=/usr/jails/test installworld

This jail directory, as the first responder hinted, can be used with bhyve, but I find it easier to configure a jail or even just use chroot.

I like to configure my jails in /etc/rc.conf instead of /etc/jail.conf:

Example /etc/rc.conf contents:

   jail_enable="YES"
   jail_list="test"

   jail_test_rootdir="/usr/jails/test"
   jail_test_hostname="test"
   jail_test_devfs_enable="YES"

I can provide more in-depth examples, ones where the jail has a private networking stack so you can SSH into it, for example, but I don't get the sense that a networking stack is important to your testing from the posted question.

You can see the running jail with "jls" and you can enter the running jail with "jexec test bash"

Inside the jail you can test your changes.

When doing this kind of sandboxing, jails work so long as the /usr/src that you built/installed to the jail is from a release that is:

  1. Older than the guest OS, or
  2. In the same STABLE branch as the guest OS, or
  3. At the very least binary-compatible with the guest OS

Situations 1 and 2 are pretty safe, while situation 3 (e.g., running a newer /usr/src than the guest OS) can get dodgy. For example, trying to run /usr/src head (13.0-CURRENT) on a 12.0-RELEASE-pX guest OS where the KBI, KPI, and API can all differ between kernel and userland (with jails, each jail runs under the guest OS's kernel).

If you find that you have to run the newest sources against an older guest OS, then bhyve is definitely the solution. You would take that jail directory and instead of running a jail with that root directory, run a bhyve instance with the jail directory as its root. I don't use bhyve that often, so I can't recall if you first have to deposit the contents inside a disk image and point bhyve at the disk image first -- others and/or Google would know the answer to that.

user3527600
  • 76
  • 2
0

I'm a ports committer, not a src one, but AFAIK running CURRENT is a common practice amongst developers.

Another way to work is to setup a CURRENT VM, share it over NFS, mount from the host and install into by running make install DESTDIR=/mnt/current. You can use BHyVe for virtualizing, by the way.

arrowd
  • 33,231
  • 8
  • 79
  • 110