Hacker News new | comments | ask | show | jobs | submit login
Writing a NetBSD kernel module (saurvs.github.io)
101 points by luu on July 2, 2017 | hide | past | web | favorite | 14 comments



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.


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.


What does systemd have to do with device drivers?


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


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.


SystemD is a cancer.


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.


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


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


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?


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


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.


Rumpkernel is even used in the GNU Hurd, because it is relatively easy to run it in userspace. This is how Hurd got audio drivers.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: