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