
Writing a NetBSD kernel module - luu
https://saurvs.github.io/post/writing-netbsd-kern-mod/
======
bitwize
I wrote a character device driver for NetBSD using almost _nothing but the man
pages_. That's how _freaking_ good the BSD docunentation is.

In terms of code and doco quality, the BSDs set a standard we should all
strive for.

~~~
tenterhooks
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.

~~~
icebraining
What does systemd have to do with device drivers?

~~~
tvgggghh
Clearly, the systemd cabal is plotting to have Linux run drivers in userspace,
just so that systemd will manage them.

~~~
yjftsjthsd-h
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.

------
raimue
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.

~~~
monocasa
The kernel grabs a mutex on the device before calling d_read or d_write.

[https://nxr.netbsd.org/xref/src/sys/kern/subr_devsw.c#905](https://nxr.netbsd.org/xref/src/sys/kern/subr_devsw.c#905)

~~~
raimue
Thank you for clearing up my doubts. I appreciate the link to the relevant
code section.

------
sgt
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?

~~~
musha68k
Not NetBSD per se but apart from MirageOS there is nothing as promising than
the "Rumpkernel" NetBSD spin-off in the Unikernel space.

It's a direct outcome of the clean and highly modular codebase that has made
NetBSD run "on your toaster" for so many years:

[http://rumpkernel.org](http://rumpkernel.org)

~~~
wahern
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.

