1) Unify sys_reboot to be MI

  • Where: kernel MI & MD
  • Difficulty: easy

Started by uebayasi@ in 2014 the goal is to ends towards a single MI (Machine Independent) code path when halting or rebooting a machine. The idea is to move the content of the actual MD boot() functions into the MI reboot(). Unless you have all architectures to tests, it might be easier to take the opposite approach and convert an architecture at a time to a MI boot(), just like we did to move from MD to MI mutexes.

2) Convert nm(1) to libelf

  • Where: userland & ELF
  • Difficulty: easy

Now that OpenBSD includes libelf there's a consensus that it would make sense to get rid of duplicate ELF parsers. Gradually building knowledge and finding bugs in the library is what this project is about. nm(1) might be an easy tool to start this journey.

3) Reduce kvm(3) usages in port

  • Where: multiple ports
  • Difficulty: easy

Using the kvm(3) interface is almost never justified and comes with the requirement of being able to read kernel memory. In other words being root. In 2019 many ports still link to the libkvm. The reason is generally historical: nobody invested time to use another interface. kvm_getprocs(3) should be easily replaced by a sysctl(2) call, see top(1)'s getprocs() for example. devel/libgtop2 has many patches that can also be taken as example.

It would be also interesting to investigate if an alternative to kvm_getfiles(3) with KVM_NO_FILES is possible, such that applications do not have to link with libkvm to issue a sysctl(2).

4) From libusbhid to devel/libusb1

  • Where: multiple ports
  • Difficulty: medium

Many ports that link to libusbhid on OpenBSD generally use a libusb backend on other OSes. Switching them to devel/libusb1 on OpenBSD would help all ports depending on this library and reduce the maintenance burden of having a different backend. Depending on the new port might be straightforward or require some coding.

5) procmap(1) without kvm(3)?

  • Where: userland & UVM interface
  • Difficulty: medium

In 2015 I started a procmap(1) rewrite based on the KERN_PROC_VMMAP sysctl(2). The question is how much of the actual tool can we rewrite without needing kvm(3)? What to do with the rest?

6) free(9) sizes

  • Where: kernel
  • Difficulty: easy

During a pizza party at g2k14 tedu@ managed to sneak a new argument to all free(9) calls. 5 years later we're still trying to fill them all to be able to play with the underlying changes! This is more about having the right hardware to test your changes.

7) Patience diff(1) and diff3(1)

  • Where: userland
  • Difficulty: medium / hard

The various copies of diff in OpenBSD's tree and devel/got could benefit from the patience algorithm.

8) Embrace SMR_LIST_FOREACH(9)

  • Where: network stack (kernel)
  • Difficulty: medium

Many lock-free list in the network stack are still using SRPL_FOREACH(9), a SRP-based data structure. The new trend is SMR_LIST_FOREACH(9) which doesn't require reference counting. Multiple examples are already in-tree.

If you're interested in lock-free algorithm this task is for you :)

9) Convert RB_* into RBT_*

  • Where: drm & pf (kernel and userland)
  • Difficulty: medium

As long as two similar APIs exist they will proliferate. The RBT_* conversion front need your help to convert the remaining red-black trees and make sure userland still work with this new API.

Once the kernel is finished we see that userland still uses the RB_* API, so would it make sense to use the RBT_* implementation with the RB interface?

10) flockfile(3) without __thrsleep(2)

  • Where: libc
  • Difficulty: medium

Now that mutexes are part of the libc it should be possible to use them to implement flockfile(3). That would allow us to get rid of the actual _thread_flockfile() implementation relying on __thrsleep(2) to reimplement locks.

Thanks for reading! If you pick a project, no need to claim anything. No need to send me an email or whatever. Just mail your diff to tech@ with an explanation of why it should be included.

Please, do not take my words as an authority ;)