Hacker News Reader

Comment by axaxs | Hacker News Reader

I think AST did. IMHO, drivers belong in user space. There's an exponential number of devices out there, jamming them into the kernel has been a messy chore at best.

View on HN

As someone completely alien to that side of computing except rudimentary stuff most people know, I never understood the reason why the drivers have to be maintained in the kernel tree. Maybe include the most common stuff, but why not have a second, distinct linux-drivers project that maintains those stuff in their own time?

Also, why we don't have a common interface to drivers at least between Linux and BSD by now? I don't like that there's animosity between the two ecosystems. That way we could have, if technicalities permit, a way for many diverse OS models to enter into the competition: if the drivers are written agains a certain standardised interface, one can code-up an OS to support that interface, and just like with POSIX, the OS would have a whole suite of drivers available from day one. Better for the driver authors too.

Linux kernel maintainers are actively hostile to the concept of a stable driver ABI. They believe that drivers are best maintained with the kernel so that they can be kept up and fixed.

Given that Linux has the broadest hardware support of any open source OS, and arguably any OS period, it's difficult to say they aren't right.

Which is exactly what Project Treble introduces, it converts Linux into a micro-kernel design, where each driver runs in its own process with a tiny kernel presence, communicating over Android RPC mechanisms.

https://source.android.com/devices/architecture/hidl/

Are Treble drivers compatible with Fuchsia? That'd be cool.

No idea, but I don't think so as they are completely different architectures.

Genode has an ABI for userspace (which includes OS components and drivers) that works across multiple kernels, which are mostly microkernels, but also Linux.

Considering Google designed both Treble and Fuchsia, it's not such a crazy idea.

Nit: AIUI, the kernel has no stable API. It has no ABI period.

There has to be an ABI in order for loadable kernel modules to exist. That's the part that's infamously unstable.

API stability is not guaranteed, though it's stable enough that the likes of Nvidia can write installers for their proprietary drivers that recompile a bit of interface glue between kernel and blob.

> There has to be an ABI in order for loadable kernel modules to exist

Given a particular install, yes, but it will change independent of kernel version based on e.g. build flags and even conceivably compiler chosen, etc.

> it's stable enough that the likes of Nvidia can write installers for their proprietary drivers that recompile a bit of interface glue between kernel and blob

Well...they certainly can. It also can infuriate me beyond all reason...

The way I've understood it is that proprietary kernel modules contain an opensource part that is included in the kernel which makes a small stable API available which is then used by the proprietary kernel modules.

Making a stable API that covers the entire kernel would be a monumental task on the other hand.

I'm not saying they are explicitly wrong, but I don't think that's a useful metric. Adoption drives the drivers, not design. That's close to saying Linus was right because Linux is more used than Minix. As a fellow HNer has pointed out, companies are figuring out that depending on hardware vendors to do the right thing is a bad idea, hence Project Treble. Then again, I have a feeling it won't be too long until they scrap linux altogether.

> That's close to saying Linus was right because Linux is more used than Minix.

Well, Linus chose usefulness as a higher priority than theoretically optimal, so by Linus's standards, yes, Linus was right.

> Then again, I have a feeling it won't be too long until they scrap linux altogether.

Um... don't hold your breath. I think you're going to be waiting a long time for that one.

Sorry if my last point wasn't clear, I was speaking strictly of Google/Treble. Fuschia seems to be coming right along, I can see them going live with it within a few years.

It sounds very interesting... I rarely go deeper that connected systems or application development myself. But would love to see some better underpinnings to a flexible UI/UX on top. I think there's lots of room for both.

They are maintained in the kernel because the kernel interfaces are not stable, by choice. Here is the explanation from the kernel docs:

https://github.com/torvalds/linux/blob/master/Documentation/...

That's exactly the kind of dismissive, arrogant nonsense that I won't bother reading, even if it is the formula to an infinite life:

> You think you want a stable kernel interface, but you really do not, and you don't even know it.

...

> It's only the odd person who wants to write a kernel driver that ...

And:

> stable-api-nonsense.rst

Yeah right, read the couple lines that are intented as one-line TLDR and dismiss it as arrogant nonsense; you probably won't be writing drivers anyway.

The document itself is a blunt dismissal it seems, anyways. And yes, I won't write any drivers if I can avoid it.

Keeping a common interface is hard.

Isn't it harder to keep rewriting stuff?

Apparently not ;)

Because a kernel is the interface between applications and hardware resources. Modern microkernels are ~50% architecture dependent code.

Creating a common interface would require all OS vendors to collaborate on some standard and maintain a leaky abstraction over their preferred abstraction. You can do that, but there are feature, performance, and maintenance compromises that must be made.

I didn't read the web, but is there a way to have a kernel running, listing what drivers it uses and afterwards, provide a configuration to recompile it with just those drivers (hence removing the bloat).. Or maybe that's not the way it goes, Linux just load the drivers it needs...

Yes it's called modprobed-db. But it only tracks what modules are loaded, not what's used in the kernel. Although maybe you could compile everything you can as modules first, then check what's loaded and then compile with all those modules build in.

Reply on news.ycombinator.com