6 ms·

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one ca

It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. That way, interesting kernels like this one can just comply with that and the enormous amounts of Linux modules can be ported to comply with that standard so that they can also be loaded by redox, blueos,etc.. But the complication I suppose is data-structures being accessed by drivers that reside in the core kernel and other assumptions that come with linking against a monolith program like the Linux kernel. It would be momentous to simply get Linux drivers to comply with a kernel-agnostic ABI.

jervant 1y ago
Maybe hardware should start offering virtio interfaces
Ericson2314 1y ago
Yes, we really really need to do this. It would be what LLVM was for compiler frontends (and thus languages) starting 15-20 years ago: a Cambrian explosion enabler.
- pjmlp 1y ago
  LLVM might be the most sucessful one, but it hardly the first of its kind. Here one famous one from early 1980s, there others to read about, for anyone into compiler tooling history, https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
  - Ericson2314 1y ago
    Thanks, that is some nice history
pjmlp 1y ago
Besides any technical issues, the issue in the Linux world is FOSS religion. Most other OSes have had driver ABIs throughout all their existence.
heavyset_go 1y ago
IMO, the reason we have a sea of open source drivers available now is because of the lack of a standard driver interface. If one existed, companies would not be compelled to release their drivers' source, and would just release closed source drivers. As it stands, kernel drivers must be open source because the kernel API/ABI changes, and drivers must be recompiled against new kernel releases. It's infeasible to release a compiled driver .ko and have it work with new kernel releases. Similarly, companies will not be incentivized to mainline their drivers for hardware outside of hobbists' interests. We're blessed with a plethora of drivers for enterprise, cloud and industry hardware that would otherwise have never been released beyond vendors' customers' deployments. What would happen to the Linux driver ecosystem is what happened with Nintendo, Sony, Apple and FreeBSD. You get closed source drivers siloed away in proprietary systems that will never be released. The deployed drivers will come with restrictions on use and distribution, as well, so it wouldn't be like you could pluck out compatible drivers to use elsewhere.
- fragmede 1y ago
  > It's infeasible to release a compiled driver .ko and have it work with new kernel releases. It's not. At Ksplice we had a build farm and whenever a supported distro would release a new kernel, we would generate new .ko files for that kernel, usually within 24 hours. It was a lot of work, and very much specific to the Ksplice product. These days, between docker and DKMS, and limiting yourself to supporting a specific device, you'd have a much easier time of building a build farm to release a compiled .ko, if you were a hardware manufacturer that wanted to support that.
  - rbanffy 1y ago
    In any case, proprietary drivers would need to be distributed separately from the Linux kernel because of the GPL license.
  - tssva 1y ago
    I’m confused. That fact that you had to recompile for each new kernel reinforces the quote you are seeking to challenge.
MisterTea 1y ago
> It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. Plan 9 does this but instead of a binary interface that exposes machine details it hides them behind 9P, a simple RPC file tree protocol. This same protocol is also served by user space programs so it's universal. The benefit of all this is the system is small and very light weight. Its an OS a single human can grok from kernel to user space. Since 9p abstracts everything it's kernel and language agnostic. A Plan 9 kernel can be written in Rust and serve the same 9P tree to a Plan 9 written in C, Go, Zig, D, etc. The user space drivers and services can also be written in any language as well as the programs accessing them. 9P is machine agnostic so a Plan 9 network can be made of disparate machine architectures letting you mix x86, Arm, Power, Mips, Risc-V, etc. Stupid simple cross compiling is an out of the box feature, just change the objtype env variable. I can export those devices/services to other systems using 9P, cifs, nfs, and so on. I can export the sound device of a Plan 9 machine using cifs to a Windows box and a Windows program could open that file and play sound by writing 16bit stereo audio to it. Your data structures are then pretty strait forward, e.g audio(3): "Audio data is a sequence of stereo samples, left sample first. Each sample is a 16 bit little-endian two's complement integer; the default sampling rate is 44.1 kHz." http://man.postnix.pw/9front/3/audio http://man.postnix.pw/9front/3/audio It's a fantastic concept which frees all the services and hardware from the confines of a old school POSIX/Unix machine. Since Plan 9 in NOT Unix you also don't have to worry about crusty old POSIX. It has its own C dialect that is mostly C99 compliant and a very nice C library that beats smelly old ANSI C. I highly recommend learning how it works and giving it a go. Its not for everyone but man, I really dig how its just a patch-bay of networked 9P stuff. Wiring up a network of machines and hardware is ezpz.
- phatskat 1y ago
  I was always fascinated by plan 9 ever since finding out about it and only ever having heard of the movie referenced in Seinfeld. Way back then I didn’t think it would keep seeing use and development, I’m glad I’m wrong :)
fithisux 1y ago
No standard interface but open documentation suitable for developers and an attempt to minimize differences

jervant 1y ago

Maybe hardware should start offering virtio interfaces

Ericson2314 1y ago

Yes, we really really need to do this. It would be what LLVM was for compiler frontends (and thus languages) starting 15-20 years ago: a Cambrian explosion enabler.

pjmlp 1y ago
LLVM might be the most sucessful one, but it hardly the first of its kind. Here one famous one from early 1980s, there others to read about, for anyone into compiler tooling history, https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
- Ericson2314 1y ago
  Thanks, that is some nice history

pjmlp 1y ago

Besides any technical issues, the issue in the Linux world is FOSS religion. Most other OSes have had driver ABIs throughout all their existence.

heavyset_go 1y ago

IMO, the reason we have a sea of open source drivers available now is because of the lack of a standard driver interface. If one existed, companies would not be compelled to release their drivers' source, and would just release closed source drivers. As it stands, kernel drivers must be open source because the kernel API/ABI changes, and drivers must be recompiled against new kernel releases. It's infeasible to release a compiled driver .ko and have it work with new kernel releases. Similarly, companies will not be incentivized to mainline their drivers for hardware outside of hobbists' interests. We're blessed with a plethora of drivers for enterprise, cloud and industry hardware that would otherwise have never been released beyond vendors' customers' deployments. What would happen to the Linux driver ecosystem is what happened with Nintendo, Sony, Apple and FreeBSD. You get closed source drivers siloed away in proprietary systems that will never be released. The deployed drivers will come with restrictions on use and distribution, as well, so it wouldn't be like you could pluck out compatible drivers to use elsewhere.

fragmede 1y ago
> It's infeasible to release a compiled driver .ko and have it work with new kernel releases. It's not. At Ksplice we had a build farm and whenever a supported distro would release a new kernel, we would generate new .ko files for that kernel, usually within 24 hours. It was a lot of work, and very much specific to the Ksplice product. These days, between docker and DKMS, and limiting yourself to supporting a specific device, you'd have a much easier time of building a build farm to release a compiled .ko, if you were a hardware manufacturer that wanted to support that.
- rbanffy 1y ago
  In any case, proprietary drivers would need to be distributed separately from the Linux kernel because of the GPL license.
- tssva 1y ago
  I’m confused. That fact that you had to recompile for each new kernel reinforces the quote you are seeking to challenge.

MisterTea 1y ago

> It would be neat if there was a standard interface for device drivers, similar to what POSIX does for user-space. Plan 9 does this but instead of a binary interface that exposes machine details it hides them behind 9P, a simple RPC file tree protocol. This same protocol is also served by user space programs so it's universal. The benefit of all this is the system is small and very light weight. Its an OS a single human can grok from kernel to user space. Since 9p abstracts everything it's kernel and language agnostic. A Plan 9 kernel can be written in Rust and serve the same 9P tree to a Plan 9 written in C, Go, Zig, D, etc. The user space drivers and services can also be written in any language as well as the programs accessing them. 9P is machine agnostic so a Plan 9 network can be made of disparate machine architectures letting you mix x86, Arm, Power, Mips, Risc-V, etc. Stupid simple cross compiling is an out of the box feature, just change the objtype env variable. I can export those devices/services to other systems using 9P, cifs, nfs, and so on. I can export the sound device of a Plan 9 machine using cifs to a Windows box and a Windows program could open that file and play sound by writing 16bit stereo audio to it. Your data structures are then pretty strait forward, e.g audio(3): "Audio data is a sequence of stereo samples, left sample first. Each sample is a 16 bit little-endian two's complement integer; the default sampling rate is 44.1 kHz." http://man.postnix.pw/9front/3/audio http://man.postnix.pw/9front/3/audio It's a fantastic concept which frees all the services and hardware from the confines of a old school POSIX/Unix machine. Since Plan 9 in NOT Unix you also don't have to worry about crusty old POSIX. It has its own C dialect that is mostly C99 compliant and a very nice C library that beats smelly old ANSI C. I highly recommend learning how it works and giving it a go. Its not for everyone but man, I really dig how its just a patch-bay of networked 9P stuff. Wiring up a network of machines and hardware is ezpz.

phatskat 1y ago
I was always fascinated by plan 9 ever since finding out about it and only ever having heard of the movie referenced in Seinfeld. Way back then I didn’t think it would keep seeing use and development, I’m glad I’m wrong :)

fithisux 1y ago

No standard interface but open documentation suitable for developers and an attempt to minimize differences