A Call For More Collaboration & Harmony Among BSD Hardware Drivers

[kiffmet]

The driver situation in the BSD space is a bit frustrating for users. I'd totally like to experiment a bit with FreeBSD, but its AMDGPU drivers are too old. OpenBSD has the most recent GPU drivers, but lacks a Linux compat layer on the other hand…

It's kinda sad, that there is so much duplicated effort being made, and porting drivers between these two BSDs isn't straightforward either. I would very much appreciate a collaborative effort in this regard. Pls agree on a shared interface and work together on GPU drivers.

[kylew77]

This would be a good initiative. Back when Intel was king they developed a few drivers for FreeBSD but now not so much since AMD is pulling away in the server market. OpenBSD seems to do a good job supporting the latest Intel NICs and Wireless NICs and a good job pulling in Intel and AMD DRM whereas FreeBSD is the only BSD OS with official Nvidia support and NetBSD is the only BSD OS with Novouru Nvidia support. ZFS is supported on free and net but not DragonFly or Open. All 4 major *BSDs have incompatible UFS/FFS implementations that is also incompatible with Linux's primitive UFS support (seriously the make config option for UFS support in Linux says don't use it!). So I guess having intercompatiable file systems would be a good start!

[binarybanana]

Maybe they could put device specific drivers outside the kernel. Run a minimal VM that talks to the hardware and communicates over some device class specific high level protocol with the host system which then exposes this as just eth0 or /dev/snd or whatever, as usual. This works best with actual hardware support but even low-end SBCs come with virtualization extensions and IOMMUs nowadays. Performance should be acceptable to native like. I guess this sounds kind of like Plan9, just locally.

For some things like networking or sound you can already kinda do this manually in a hacky way. If some PCIe NIC (maybe even wireless) isn't supported on your system. Just fire up a Linux VM which connects to the network and route your traffic through it however you prefer. You can now browse the web. This also helps if the drivers are just buggy and crash your kernel.

[kylew77]

Maybe they could put device specific drivers outside the kernel. Run a minimal VM that talks to the hardware and communicates over some device class specific high level protocol with the host system which then exposes this as just eth0 or /dev/snd or whatever, as usual. This works best with actual hardware support but even low-end SBCs come with virtualization extensions and IOMMUs nowadays. Performance should be acceptable to native like. I guess this sounds kind of like Plan9, just locally.

For some things like networking or sound you can already kinda do this manually in a hacky way. If some PCIe NIC (maybe even wireless) isn't supported on your system. Just fire up a Linux VM which connects to the network and route your traffic through it however you prefer. You can now browse the web. This also helps if the drivers are just buggy and crash your kernel.

The first paragraph sounds an awful lot like a microkernel approach which how monolithic *BSD kernels are other than DragonFly I don't see gaining much traction.

The second paragraph is actually very interesting in the FreeBSD space to get wireless AC and AX working. They are implementing a basically small Linux VM that runs the Linux Intel driver for stuff like the newer iwx wifi stuff. The project is called Iwlwifi.

[toves]

... Reality is a cast iron bitch, you know. She doesn't care if you believe in her.

I would have gone for wrought iron. Cast iron is pretty brittle.

I have used all three BSDs for actual work - netbsd on a DEC Alpha 3000 turbochannel machine.
Usually a lot nicer than the proprietary Unixes of the day. All Linux now but the stability of various interfaces in BSDs is quite refreshing - if you administered a BSD box ten years ago then you wouldn't be too out of place with the current version. Cannot really say that about Linux distros in general.

A few years ago building a redundant router from commodity hardware (primary/secondary failover) with two FreeBSD boxes was much simpler than struggling with Linux. Not sure if that is still the case.

ZFS on Linux is pretty decent once the licensing nonsense is taken out of the equation. The kABI tracking packages make it pretty painless.

Horses for courses. Having choices when the reality bitch is on the prowl is a good thing.

[mxan]

The macOS screenshot on the presentation isn't helping the perception of the BSDs as toy OS's only run in virtual machines :P

[danboid]

NetBSD should merge with FreeBSD (and DragonFly). NetBSD's USP used to be its portability but I'm pretty sure FreeBSD (and Linux) runs on more platforms now so I don't really see the point in them being separate projects.

I think there's room for two BSD's. FreeBSD for most BSD fans and OpenBSD for those who are willing to sacrifice performance for security.

[dacha]

The first paragraph sounds an awful lot like a microkernel approach which how monolithic *BSD kernels are other than DragonFly I don't see gaining much traction..

Actually FreeBSD already took that approach for webcamd and fusefs-lkl. They both use parts of the Linux kernel in a user-space application, webcamd using it to provide video4linux drivers for webcams, fusefs-lkl using it to provide filesystem drivers for BTRFS, Ext4, and XFS.

[kylew77]

I'm pretty sure FreeBSD (and Linux) runs on more platforms now so I don't really see the point in them being separate projects.

Linux runs on far more architectures than FreeBSD, the 13.X series only supports AMD64, i686, ARM64, Arm7(32bit), MIPS (going away with 14.X), RISCV, 32bit POWER PC, 64 bit POWER PC, SPARC 64 (12.4 is last supported version). So with 14.0 it will be AMD64, i686, ARM64, some 32bit arm, RISCV, 32bit and 64 bit POWER PC. Only ARM64 and AMD64 are tier 1 and support binary updates. i686 is supported with binary updates when possible but is tier 2.
Alpha, Itanium, SPARC64 soon, some arm, and something called pc98 all went the way of the dodo.

NetBSD on the other hand supports more processors than I will list here but as TIER 1! Supports the regular AMD64, i386, ARM64, and 32 bit arm, but also MIPS, SPARC64, POWER PC, and XEN (virtual). Along with tier 2 and 3 stuff as esoteric as the Sega Dreamcast, VAX, Amiga, etc.

I would say it is a toss up between what supports more: Linux or NetBSD. Finding a Linux distro that supports a VAX or Amiga might be hard with so many focusing on the "4 core architectures" of AMD64, ARM64, POWER PC 64, and RISC V 64. Gentoo or Debian would be your best bet.

OpenBSD is also supported on many architectures including one or two that NetBSD doesn't but have pruned away support for several architectures over the last couple of years because in OpenBSD everything has to be self compiling and able to build the OS and ports on the hardware in question so support for architectures like Longson were dropped. But Open still supports Alpha and SPARC 64 when a lot of OS are dropping these once great power houses. luna88k is only supported by OpenBSD to the best of my knowledge.

DragonFly BSD just supports AMD64 only.