Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> NetBSD has an "anykernel" approach which separates the kernel for the drivers. So you can impose your own flavour of kernel on a bunch of pre-written drivers.

As a NetBSD developer, I don't recognize what you mean by this.



Maybe read this whitepaper:

https://www.netbsd.org/gallery/presentations/justin/2015_Asi...

“ The rump kernel has been used as a way to supply device drivers in other new operating systems, which do not yet have a full set of device drivers. For example, Genode[4] is a framework for building microkernel operating sys- tems using the L4 family of microkernels. Genode uses the rump kernel to provide file system support, so that it does not have to develop its own file systems.”

Here’s a 362 page dissertation on rump kernels which has a netbsd focus:

http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049...

There’s also the Wikipedia entry.

https://en.m.wikipedia.org/wiki/Rump_kernel


That isn't how device drivers are used in NetBSD though, it is a different way of compiling them for other targets.


From the white paper published on netbsd.org:

“ An implementation that does this ships with NetBSD, allowing the NetBSD drivers to be run in NetBSD userspace… The first major PCI driver developed was the In- tel Centrino 7260 driver developed for NetBSD and OpenBSD by Antti Kantee. The commit message said “This is probably the world’s first Canadian cross device driver: it was created for OpenBSD by writing and port- ing a NetBSD driver which was developed in a rump ker- nel in Linux userspace.”[13]

Further, just another example, from page 149 in the dissertation is an extended many page discussion of how the rump kernel was used to provide usb support in netbsd.

http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049...

“ We implemented a host controller called ugenhc. When the kernel’s device autocon- figuration subsystem calls the ugenhc driver to probe the device, the ugenhc driver tries to open /dev/ugen on the host. If the open is successful, the host kernel has attached a device to the respective ugen instance and ugenhc can return a successful match. Next, the ugenhc driver is attached in the rump kernel, along with a USB bus and a USB root hub. The root hub driver explores the bus to see which devices are connected to it, causing the probes to be delivered first to ugenhc and through /dev/ugen to the host kernel and finally to the actual hardware. Figure 3.24 con- tains a “dmesg” of a server with four ugenhc devices configured and one USB mass media attached.”

¯\_(ツ)_/¯


> ¯\_(ツ)_/¯

UTSL.

The author used rump to develop the drivers, it isn't used to run them in a production NetBSD kernel.


But running on other targets is exactly what people are excited about?




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

Search: