Hacker News new | ask | show | jobs
by tatetian16 361 days ago
> keeping the driver interface unstable is his moat

Maybe we will have young and hungry AI-for-system researchers who would like to take on the job of developing AI agents that translate Linux drivers in C to Asterinas ones in (safe) Rust.

Another feasible approach is to reuse Linux drivers by running a Linux kernel inside some kind of isolated environments. For example, the HongMeng kernel leverages User-Mode Linux to reuse Linux drivers on HongMeng [1]. Asterinas can take a similar approach.

[1] https://www.usenix.org/conference/osdi24/presentation/chen-h...

4 comments

The bottleneck, for the most part, is actually being able to test them. Even a translation by a skilled engineer is liable to have issues if they don't actually have the hardware to test things out. Linux's driver support is built out mainly by people doing that, either hobbyists scratching their own itch of hardware they own or manufacturers contributing drivers for their own hardware.

(It's also why regressions are pretty common: it's completely infeasible to test all of linux on each release, some people test some parts of it, but it's all very ad-hoc, very little is automated, and it's not at all unified)

OKL4, deployed on tons of phones, had the ability to run drivers stand alone or in driver VM's that wrapped them. Other guests could call either. I think Genode uses a similar, L4-based component.

There was also an academic project that combined virtualization with Windows drivers.

If you port drivers from Linux those drivers would have to be GPLv2-licensed.
That needn't be a problem, assuming the linking-clause of the GPL2 doesn't extend to device drivers. Gpl2 doesn't extend to userspace processes linking into the kernel, so maybe?
Yeah but unless the drivers run like microkernel services in a separate userspace, the GPL applies to anything you link into your kernel
This is the future. Hardware has already standardized more towards USB HID than in previous decades, Linus interview included. When AI can develop these device drivers based on just probing the HID info, we’ll be on Cloud9. Because maybe then, we’ll get the year of the Linux desktop.
Such standard interfaces are rarely the problem, though there is often a headache of dealing with the pile of 'quirky' hardware that just so happens to work well enough with exactly what windows happens to do. The pain point is all the things that aren't that. Nonstandard, niche hardware which maybe has a few thousand users, or big and complex interfaces like graphics cards which are basically whole OSs on their own.
Pretty sure if your device actually just uses USB HID, it already works on Linux without a custom driver.

What requires a custom driver is when your device adds its own non standard features.

USB it's a nightmare.
Sarcasm is too for some
Yeah, it's very easy. Real devices usually adhere to the specs.. only very few exceptions: https://github.com/torvalds/linux/blame/master/drivers/hid/h... .. /s