Val Packett 🧉<p>The <a href="https://social.treehouse.systems/tags/Rust" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Rust</span></a> for <a href="https://social.treehouse.systems/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a> debacle should be a wake-up call for accelerating safe OS innovation.</p><p><a href="https://social.treehouse.systems/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a> proves you can reuse huge pieces of Linux, with GPU and WiFi drivers ported in kernel space (LinuxKPI) and USB (input, video capture, etc.) drivers running in userspace (webcamd – RIP Hans 😔). This all in a relatively sustainable way with a very small group of developers.</p><p>What we need to be building is kind of an inverse of R4L, a "Linux for Rust", a common Driver Depenguinator, a successor to webcamd that would port Linux drivers to a common abstraction layer (like embedded-hal but not so embedded) that would be implemented for both Linux/BSD userspace (w/ CUSE, uinput, UIO, udmabuf, /dev/mem, etc.) and various microkernels like <a href="https://social.treehouse.systems/tags/Redox" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Redox</span></a>.</p><p>That would be an LSP-style "NxM to N+M" moment for OSdev, instantly making microkernel projects a lot more viable in practice.</p>