It's where we should all be striving for I think. I recently did the Eudyptula challenge, and it was like wading into a morass of nonsense when it got to device drivers.
Whoever started that systemd thing should be ashamed.
You jest, but systemd (the project, not exactly the PID 1) already handles device recognition (udev) and after they rolled in a bootloader, NTP, and DNS, I wouldn't even be surprised anymore.
Does the NetBSD kernel itself already ensure mutual exclusion of read and write functions on the same device?
Otherwise, I see a use-after-free here. A read could occur right after the write function free'd the old buffer in sc.buf, but before assigning a new pointer value. The read function would be able to read kernel memory via the old buffer pointer, although the memory pages pointed to may already have been reused for something else.
If my assumption is correct, the solution would be to use a mutex object to make the read block while the write updates the buffer.
I used to run NetBSD about 15 years ago but I haven't even spared it a thought for at least 3-4 years. Is the community and codebase still active - and does NetBSD still have an edge in some areas?
Is the rumpkernel truly a spin-off? It originated in NetBSD master and my understanding is that they'll continue maintaining it going forward. It's part of their system design.
Contrast that with rump Linux kernels: maintained completely out-of-tree and, AFAIK, very little interest in merging and maintaining a complete rump environment in mainline. Rump kernels are easier in NetBSD, anyhow, because of their very carefully designed and maintained device subsystems.
Yes, NetBSD is still active, I'm using it to post this.
For me, the community is a big part of the reason I use it. The codebase still feels as if it hits a good balance between having the features that I need for daily use and still being clean enough to see how new stuff could be added.
In terms of code and doco quality, the BSDs set a standard we should all strive for.