Following a discussion on tech@ [initiated by a post with patch from Ted Unangst (tedu@)], the "TearFree" option has been backported to the xenocara modesetting(4) driver in -current:

CVSROOT:	/cvs
Module name:	xenocara
Changes by:	matthieu@cvs.openbsd.org	2025/06/09 12:18:36

Modified files:
	xserver/dix    : pixmap.c 
	xserver/hw/xfree86/common: xf86Mode.c 
	xserver/hw/xfree86/drivers/modesetting: dri2.c driver.c driver.h 
	                                        drmmode_display.c 
	                                        drmmode_display.h 
	                                        dumb_bo.c meson.build 
	                                        modesetting.man 
	                                        pageflip.c present.c 
	                                        vblank.c 
	xserver/hw/xfree86/modes: xf86Crtc.h xf86Rotate.c 
	xserver/include: displaymode.h pixmap.h 
	xserver/present: present.h present_screen.c 

Log message:
Backport TearFree page flips for the modesetting driver from X.Org maaster.

Work done by tedu@ based on previous diffs by jcs@ and stsp@.
One bug fix in master by me. tested and ok tb@. commit on behalf of tedu@

The option is on by default, so users of the relevant hardware can expect smooth(er) scrolling ahead.

Rafael Sadowski (rsadowski@), OpenBSD developer and prolific blogger, has been looking into file system performance optimizations on our favorite operating system, and is now sharing his tips and tricks in FFS optimizations with dirhash on his blog.

He leads in with a TL;DR:

tl;dr

Consider playing with sysctl vfs.ffs.dirhash_maxmem to increase the maximum dirhash cache.

That said, it is worth your time to read the whole thing!

Version 0.113 of Game of Trees has been released (and the port updated):

• tweak 'got status' and 'got add' ignores handling for better git compatibility
• improve redundant pack detection during 'gotadmin cleanup'
• gotwebd: do not forget to initialize *ngroups argument for getgrouplist()
• fix default access for root and _gotd when gotsysd runs without config file
• fix bogus "unexpected privsep message" from gotsh during 'got send'
• fix a race in gotd notification processing causing notify process to exit

In a multi-part article, kraileth reviews the installers of various BSD operating systems.

Part 2 covers OpenBSD:

https://eerielinux.wordpress.com/2025/04/27/installing-bsd-in-2025-part-2-a-critical-look-at-openbsds-installer/

That's how it looks from the outside coming in, folks!

Fresh from the just concluded j2k25 hackathon in Nara, Japan, Rafael Sadowski (rsadowski@) has published his report on his blog:

Week 2: The j2k25 Japan Hackathon

We arrived in Nara during the late afternoon. After checking into our hotel, goda@, my wife and I headed straight to the hack room. My initial thought was to finally do some ports hacking to warm up and create a plan for the upcoming week. I hadn't had much opportunity for focused thinking during our busy week in Tokyo.

As soon as I booted OpenBSD, kn@ appeared. I was genuinely happy to see him again, and we spent the first half hour catching up. Then he mentioned we were about to head to the team event. This completely derailed my planned "first day" approach - instead of keyboard and OpenBSD work, the evening was filled with excellent food, beer, and funny conversations.

Reining in file system access is hard to get right, even for OpenBSD developers.

In a message to tech@ titled openat(2) is mostly useless, sadly Theo de Raadt (deraadt@) describes how the openat(2) family of system calls has failed to live up to expectations in practice, and he proposes changes that may improve the situation.

Theo writes,

List:       openbsd-tech
Subject:    openat(2) is mostly useless, sadly
From:       "Theo de Raadt" <deraadt () openbsd ! org>
Date:       2025-05-28 14:03:29

The family of system calls related to openat(2) are mostly useless in
practice, rarely used. When they are used it is often ineffectively or
even with performance-reducing results.

     int
     openat(int fd, const char *path, int flags, ...);

These are the others:

Recently, Crystal Kolipe found that attaching softraid volumes as read-only devices did not work.

Then what to do?

Fix the code and make it work, of course!

The full story is available as “Stay, (write), protected!”, taking us through the steps of adding a feature to OpenBSD. Enjoy!

A new profiling subsystem is now in OpenBSD-current, from the hands of none other than Theo de Raadt (deraadt@) himself.

A longish sequence of commits introduced the changes incrementally, with a summary as follows:

List:       openbsd-cvs
Subject:    CVS: cvs.openbsd.org: src
From:       Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date:       2025-05-24 6:49:17

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2025/05/24 00:49:17

Modified files:
	include        : unistd.h 
	sys/sys        : exec.h exec_elf.h gmon.h proc.h systm.h 
	sys/kern       : exec_elf.c init_sysent.c kern_exec.c 
	                 kern_exit.c kern_fork.c kern_pledge.c 
	                 subr_prof.c syscalls.master 

Log message:
In the old gprof profiling subsystem, the simplistic profil() syscall
told the kernel about the sample buffer, and then the normal exit-time
_mcleanup() would finalize the buffer, open()'ed a file and write out
the details.  This file opening has become increasingly impossible
because of our privsep / privdrop, chroot, setresuid uid-dropping,
pledge, unveil, and other efforts.  So people stopped using gprof.
Programs which needed profiling needed substantial mitigation removal
changes to put them under test.

Are you an OpenBSD user with a low power device such as a PC Engines APU2, with one or more em(4) network interfaces?

Darren Tucker (dtucker@) has a new diff out that may be of use to you, posted in a message to tech@:

List:       openbsd-tech
Subject:    em(4) TX interrupt mitigation
From:       Darren Tucker <dtucker () dtucker ! net>
Date:       2025-05-19 8:52:13

Hi.

TL;DR: if you use em(4), particularly on a low-power device such as a
pcengines APU2, please try this diff.

The em(4) driver has 5 interrupt mitigation timers[0].