Comment by heavyset_go | Hacker News Reader

Comment by heavyset_go | Hacker News Reader

Parent Full thread

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.

> 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.

Very cool, but I think that points to the impracticality of releasing drivers like that when it comes to distributing them to end users.

End users having to connect to the Internet to download the right drivers seems impractical?

Vendors running build farms into perpetuity so that end users can use their hardware with new kernels does seem impractical from where I'm standing, yeah.

I don't see vendors supporting their hardware for more than a few years if new kernels need new module builds regularly.

Am I misunderstanding what you were talking about?

Yeah I guess we just don't agree on what's practical. For a million dollars over the course of, let's say, five years for support, you could get someone to do this job.

AMD, Nvidia, Broadcom, Virtualbox, VMware, Dell, and Realtek using DKMS for their closed source drivers today, is also where I'm coming from.

I’m confused. That fact that you had to recompile for each new kernel reinforces the quote you are seeking to challenge.

What definition of "infeasible" are you using?

I’m using the definition that something can’t be done. The comment you responded to was regarding releasing a compiled ko and having it supported by newer kernels. Your response was we solved this by recompiling it.

A specific .ko file can't work against arbitrary kernels, no. The customer problem of I have a kernel and this hardware and need a .ko file for it is solvable.

That’s great but not what the comment you responded to was regarding.

In any case, proprietary drivers would need to be distributed separately from the Linux kernel because of the GPL license.

Reply on news.ycombinator.com