Hacker News Reader

Comment by fork-bomber | Hacker News Reader

Very cool!

I think a killer feature would be to emulate the Linux kernel device driver model such that existing C driver modules could be used with Kerla. Further, borrow (no pun intended!) the Linux device driver Rust wrappers from the Rust for Linux kernel project to then enable writing Linux device drivers in Rust.

The question is whether emulating the Linux device driver model (by which I kind of mean mimicking the set of core kernel services needed to support drivers - kernel threads, sync primitives, allocators etc) ends up being a massive task akin to writing the core kernel itself.

I think there might be reasonable trade offs that make the problem more tractable.

Having the ability to have a significantly simpler kernel with Rust’s memory and thread safety guarantees plus the ability to use even a small set of Linux’s massive set of drivers would be very compelling.

View on HN

Linux drivers don't have a fixed ABI (or even API), making such a feat somewhere between hard and impossible. You'd have to constantly play catch up with the latest kernel refactorings, which would require a tremendous amount of engineering effort.

Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat.

I asked this question during the recent Linux kernel plumbers conference: "How often in practice do the kernel A{B,P}Is fro device drivers change ?". I got a very mixed response.

My take away was that while 'new' driver classes/subsystems do involve more churn in the core kernel support subsystems, there is a clear trend towards convergence in terms of significant change.

If the change truly was significant and continuous then that would impede productisation with the Rust kernel. I'm not saying that the A{B,P}Is are in any way stable but I personally don't think that keeping up will be an intractable problem.

In the spirit of Kerla's authors prime motive - which appears to be hacking for knowledge - this might be something to try, perhaps with a driver class that is known to be more stable.

>Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat.

And better drivers.

Actually many Linux drivers are far better than their Windows counterparts - many Windows drivers are complete shit. It is entirely dependant on your particular hardware. I know the driver for my WiFi in my laptop is far crappier in Windows for example.

FreeBSD’s linuxkpi - bits and pieces of Linux KAPI provided to make porting Linux drivers to FreeBSD easier - works just fine, so this assumption is wrong.

> The question is whether emulating the Linux device driver model (by which I kind of mean mimicking the set of core kernel services needed to support drivers - kernel threads, sync primitives, allocators etc) ends up being a massive task akin to writing the core kernel itself.

The kernel has (deliberately) never had a simple or stable driver ABI, so I think this is potentially a huge task. And then you've also left a C-based attack surface in place.

I'm not sure what the minimal set is if you decide to only support 2021-era hardware. PCIe+SATA+framebuffer+USBhost+USBHID?

Towards the C-based attack surface:

I think using the Rust-for-linux wrappers to implement the drivers in Rust would eventually help.

Also, even if initially Linux C drivers were transplanted into Kerla that could be a net benefit if the tradeoff of wide device driver availability vs increase in the trusted compute base was acceptable.

I personally think that tradeoff would be acceptable - if the transplanting ability was tractable. It's a hard one to absolutely agree on, admittedly.

Towards the minimal set of hardware, fair point! I think that one should be able to get quite far with judicious selection of device driver classes and leave the truly in-flux classes alone ?

Maybe starting with the rumpkernel interface is easier and one could already use some of the NetBSD drivers: https://en.wikipedia.org/wiki/Rump_kernel

That's a very good point indeed.

While I completely agree that NetBSD's Rump kernel would be a great way to go (I've played with it in the past and quite like it!) I do wish there was a similar initiative bound to the Linux kernel.

The closest I've seen is Octavian Purdila's Linux-Kernel-Library project: https://lkml.org/lkml/2015/11/3/706

Not sure how far they've come though. Perhaps Kerla could be a prime mover for them ?

Reply on news.ycombinator.com