5 ms·

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

> 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-haibo https://www.usenix.org/conference/osdi24/presentation/chen-h...

reactordev 1y ago
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.
- eMPee584 1y ago
  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/hid-quirks.c https://github.com/torvalds/linux/blame/master/drivers/hid/h... .. /s
- BenjiWiebe 1y ago
  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.
- rcxdude 1y ago
  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.
  - KingLancelot 1y ago
    [dead]
- anthk 1y ago
  USB it's a nightmare.
  - reactordev 1y ago
    Sarcasm is too for some
- KingLancelot 1y ago
  [dead]
rcxdude 1y ago
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)
nickpsecurity 1y ago
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.
tuna74 1y ago
If you port drivers from Linux those drivers would have to be GPLv2-licensed.
- kvdveer 1y ago
  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?
  - qalmakka 1y ago
    Yeah but unless the drivers run like microkernel services in a separate userspace, the GPL applies to anything you link into your kernel

reactordev 1y ago

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.

eMPee584 1y ago
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/hid-quirks.c https://github.com/torvalds/linux/blame/master/drivers/hid/h... .. /s
BenjiWiebe 1y ago
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.
rcxdude 1y ago
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.
- KingLancelot 1y ago
  [dead]
anthk 1y ago
USB it's a nightmare.
- reactordev 1y ago
  Sarcasm is too for some
KingLancelot 1y ago
[dead]

rcxdude 1y ago

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)

nickpsecurity 1y ago

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.

tuna74 1y ago

If you port drivers from Linux those drivers would have to be GPLv2-licensed.

kvdveer 1y ago
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?
- qalmakka 1y ago
  Yeah but unless the drivers run like microkernel services in a separate userspace, the GPL applies to anything you link into your kernel