Unified approach to drivers reddit / BSD ---------------------------------------------------------------------- demetrioussharpe · 2021-05-07 16:21 In regards to drivers, Linux is ahead of us in many regards. In the case of video drivers, they’re definitely eating our lunch. Would it be possible for all of the main BSD families to work based on a unified device driver base architecture & unified architectures for WiFi, Bluetooth, & GPU drivers? After all, we all see that trying to share with the Linux driver framework simply isn’t working out. ---------------------------------------------------------------------- ctisred · 2021-05-07 17:52 Not really - drivers need to do things like manage kernel locks, allocate memory from the kernel, interface with higher-level kernel layers like filesystem or network apis, etc. which have all deviated from CSRG BSD in project specific ways. Perhaps some compatibility layer could be possible, but it would require quite a bit of effort on its own and would always create inferior drivers as compared to ones written or adapted to native interfaces. ---------------------------------------------------------------------- demetrioussharpe · 2021-05-07 17:54 Oh, ok. ---------------------------------------------------------------------- AbsolutelyLudicrous · 2021-05-07 17:55 Look into NetBSD's RUMP kernels - the trouble is that nobody uses them ---------------------------------------------------------------------- BlatantMediocrity · 2021-05-07 19:17 Wouldn’t they have a performance penalty because you’re running a mini-kernel? And then it might not be appropriate for Wi-Fi, Bluetooth, and GPU drivers as indicated by OP? (I’m way out of my depth here.) ---------------------------------------------------------------------- NeverSawAvatar · 2021-05-07 19:22 There has been an insane amount of work to get graphics where they are, it's effectively the most complex device most systems have. Start with a clean interface, linux took a decade to move to kms and clean out drm to the point it mostly works now. The key is Mesa integration (or Vulcan) the interface to one of these has to be clean, with the raw fb preferably layered on top very lightly or easily factored out. Linux was a nightmare forever, but Mesa does most of the heavy lifting now, you just need a clean mapping interface and straightforward way to alloc command lists. ---------------------------------------------------------------------- nia_netbsd · 2021-05-07 19:47 WiFi drivers get ported between different BSDs frequently already. GPU drivers are hard because the hardware is incredibly complex and not really documented. The code comes from Linux because that's what the hardware vendors write drivers for. ---------------------------------------------------------------------- Maccraft123 · 2021-05-07 21:33 For GPUs in ARM space kernel driver is often a glorified register writer ---------------------------------------------------------------------- NeverSawAvatar · 2021-05-07 22:56 90% of what kernel graphics drivers do is mmap. For Linux drm drivers there's more, but mostly allocating command lists while keeping other stuff hidden for security. Honestly drm isn't that hot, we could use a better model. ---------------------------------------------------------------------- demetrioussharpe · 2021-05-08 00:56 Honestly, that’s what I’m looking for -a better model for the BSDs, so we aren’t tied to the madness of Linux GPU driver architecture. I remember years ago when Linux & FreeBSD were sharing the DRM driver tree. Unfortunately, the Linux pieces were constantly heavily developed, while the FreeBSD portion wasn’t. The end result is what we have now -the Linux part was pulled into the Linux kernel tree while the FreeBSD part became completely irrelevant. What’s interesting is that the BeOS GPU driver model is better than both in many ways. Something like that would probably suite the BSD world much better than trying to keep up with the Linux stack. Though, we’d still have to create an API for the 3d portion of the driver. ---------------------------------------------------------------------- demetrioussharpe · 2021-05-08 00:57 It’s amazing that I got downvoted for saying “ok”. ---------------------------------------------------------------------- Maccraft123 · 2021-05-08 02:06 How is BeOS model better? ---------------------------------------------------------------------- demetrioussharpe · 2021-05-08 02:08 The kernel driver portion is analogous to Linux’s KMS driver, while the accelerant driver is used by the AppServer & handles all commands that can be handle in userspace. Anything needing kernel privileges is sent to the kernel driver portion. The API is simple & to the point. It’s not a convoluted mess. ---------------------------------------------------------------------- cyberruss · 2021-05-08 13:59 Have an upvote to compensate ---------------------------------------------------------------------- GunpowderGuy · 2023-09-20 01:34 Where can i read more about that architecture? ---------------------------------------------------------------------- demetrioussharpe · 2023-09-20 14:27 Though Be, Inc. is long dead, the open source replacement project for is HaikuOS. Check out the [HaikuOS developer documentation site](https://www.haiku-os.org/docs/develop/) for more information. ---------------------------------------------------------------------- demetrioussharpe · 2023-09-20 14:28 I'm not talking about porting, I'm talking about directly sharing the same drivers using the same code. ---------------------------------------------------------------------- GunpowderGuy · 2023-09-20 21:27 Thanks. I am looking for a non linux open source os to contribute to. I am interested on whether they could support gpu drivers without having to replicate the complexity of linux drm/kms. One viable approach i have found is interfacing linux inside a virtual machine so its drivers can be used ( redox among others are implementing this ) but ideally this should be a fallback with a propery architecture for elegant drivers being available ---------------------------------------------------------------------- nia_netbsd · 2023-09-21 10:34 Unlikely to ever happen. It is related to the fundamental question of how kernels are designed. In this area there's drastically different views, it's basically the leading cause of forks. ---------------------------------------------------------------------- demetrioussharpe · 2023-09-21 12:21 There’s already a precedent for 2 completely different kernels sharing a driver framework. If FreeBSD & Linux we’re technically able to share the DRM framework, then there’s absolutely no reason that the various BSD kernels can’t share a complete driver framework. In fact, such a framework should probably be maintained by a separate group that focuses SOLELY on the framework & drivers. ---------------------------------------------------------------------- demetrioussharpe · 2023-09-21 12:22 It’s not as if any of the BSD projects can really afford to turn down the opportunity to offload driver development to another group that specifically makes BSD drivers. ---------------------------------------------------------------------- nia_netbsd · 2023-09-21 14:48 Well, if you say so ---------------------------------------------------------------------- demetrioussharpe · 2023-09-21 16:15 The first implementations of the DRM drivers were in a tree that was shared between FreeBSD & Linux, before DRM was moved into the Linux kernel. I'm sure that I still have a copy of that old code on one of my hard drives. I had this code simply because at the time I was implementing the AGP specifications for an OS called Syllable. I grabbed a copy of the code because the next step was to implement hardware accelerated OpenGL rendering. I'd already been successful with porting TinyGL (a software-based OpenGL implementation) to Syllable.