I’d like to hear your perspective on why we can’t port drivers from Linux, aside from the licensing disputes. Does it take more time? Is it significantly more work? What do you think?
In my opinion, this hasn’t really been explained well beyond the usual “Muh GPL” argument.
There are technical reasons why it’s difficult to port Linux drivers.
Some posts about that which I could quickly find:
So yes,it is significantly more work,and not only once but again each time Linux decides to change how some kernel API works,and not updating is also not an option then since driver updates often fix bugs or add support for more devices.
With FreeBSD,the API is rather stable,there was the big task of building a compatibility layer once and now we can import updated drivers from FreeBSD rather easily.
Maybe because it’s enough explanation.
Porting GPL Linux code into Haiku will make Haiku, or at least that part of Haiku, no more compatible with the chosen license of the project.
I doesn’t mean that nothing can’t be learn from Linux drivers code, and we here and there take benefits of some finding in Linux drivers code to fix our own version of drivers code.
I guess with AI these days, many third party AI-generated drivers for Haiku are already benefiting from large part of Linux GPL’ed drivers code. So in practice, it’s already happening.
But regarding the inclusion of such ported (AI generated or not) drivers code in Haiku codebase, it will violate the Haiku project MIT license terms.
Except for drivers required at boot time in order to boot Haiku, many drivers can be delivered as a third-party package.
I’d like to note however that not all linux drivers are exclusively gpl.
For example amdgpu and intel gpu drivers are also available under a permissive license.
Of course this would need to be verified that there wasn’t some gpl code snuck “in between” anywhere… but still
Good remark, and indeed something to take into consideration may a port of this major hardware drivers from Linux world be fully ported to Haiku one day.
All good answers, but wouldn’t something like clean room reverse engineering work, it would excell drivers on Haiku. But there could be blockages such as encrypted blobs, but since the Linux kernel is starting to use AI, could those drivers ever be trusted in the future? Also I undertsand about Kernel shifts in ABI, so I guess it’d be extra work.
Sure,clean room reverse engineering would technically work,but it’s even more work than maintaining a compatibility layer for the ever-changing API,which is already too much for the small Haiku development team.
This isn’t really a question of technical possibilities,but more about available manpower and where it makes sense to spend the limited time.
It’s not so much about the license, it’s that Linux drivers depend on the Linux kernel and so they’re not very easy to port.
Yeah most drivers depend on A OS kernel, is it easy to port Linux compared to…FreeBSD let’s say.
Go look at the source code for a driver you’re interested in porting. At the top of the file you’ll see a bunch of includes like linux.h, linux_disk.h, linux_network.h, etc. There will be a dozen of these or more. You have to reimplement each of these headers on Haiku, then you can port the driver. This is the compatibility layer you need. When you build this compatibility layer you’ll understand why it is such a herculean task to port a Linux driver to Haiku. If you’re sensible you’ll give up before you get too far. That is why more Linux drivers are not ported.
The rump kernel might help in this regard. GNU Hurd uses it for drivers.
It seems these are all based on netbsd drivers Repo · rumpkernel/wiki Wiki · GitHub
That for us would not solve much, I think. Since we can just port netbsd drivers normally if we wish (and the majority mentioned in the rump site we already have. It seems to be mostly heavy 3d accel drivers, and some usb devices that we lack)
Yes, it’s the NetBSD kernel’s driver part.
Since we can just port netbsd drivers normally if we wish
The advantage (as I understand it) is that you don’t have to port drivers. You just port the rump API, and every driver comes for free.
Assuming you want them running in userspace probably. But on the other hand we already have a compat layer for FreeBSD and OpenBSD drivers, those two also share code with netbsd. Making a NetBSD compat layer would probably be easier than introducing a new userspace api layer 