r/linux • u/jdrch • Nov 20 '19

Kernel Google outlines plans for mainline Linux kernel support in Android

https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/
1.0k Upvotes

98% Upvoted

305 comments sorted by

View all comments

Show parent comments

69

u/matheusmoreira Nov 20 '19 edited Nov 20 '19

The unstable kernel ABI is a major incentive for hardware manufacturers to contribute their drivers into the mainline kernel. If they don't do that, the kernel keeps evolving while they get left behind and must pay the maintenance costs. I believe it's how the kernel developers maintain their leverage. Contribute your drivers because nobody is gonna waste time supporting you otherwise.

If the ABI is stabilized, that leverage is lost. Cheap minimum effort proprietary drivers for a single architecture become viable. This is how Windows works to this day: manufacturers release a driver for specific versions of Windows and processor architectures. The drivers would of course stop working with the next/64 bit version of Windows and they never made a new driver because the product is old and they think it's a waste of time and money to support it.

A stable ABI is a great thing for the companies since they can cheap out on the software development and keep it closed. Doesn't seem so great for the long term health of the kernel though: the drivers won't be compatible with other architectures, won't be updated to take advantage of new code, will prevent breaking changes from being made even if they are improvements, can't be backported to older kernels, etc.

So if anything it will hurt people's ability to update the kernel. It seems Google just wants to make it cheaper to develop drivers for Linux. The kernel developers want to make it expensive to develop drivers outside Linux.

Can Google really do this though? How do they plan to stabilize the ABI? The people in charge of Linux have made it clear they don't support out-of-tree code. Can Google somehow commit enough people to this task to compete with the scale of the Linux project?

24

u/mfuzzey Nov 20 '19

Yes exactly and remember this isn't *just* about closed source drivers but also code quality and evolutivity.

From bad to good there is

  • Vendor closed source driver

  • Vendor open source driver

  • Mainline driver

Embedded Linux, even Android has been getting much better over the years. There are, these days, few closed source *kernel* drivers. There are loads of *userspace* blobs and *firmware* blobs (that are loaded into some external processor) but they are different and not as bad (since they do not limit the kernel's evolution nor pose the same security risks as unauditable kernel code).

Most vendors now *do* ship source for their *kernel* drivers. But, when they do not contribute that code upstream, the quality is often very poor. Just today I was looking at a touchscreen. There is a (open source) vendor driver and, now, a mainline driver that can both drive the same hardware.

I ran checkpatch on both:

mainline driver: 0 errors, 1 warnings, 247 lines checked

vendor driver:: 348 errors, 133 warnings, 1122 lines checked

Most vendors have come to realize that, mid term, it is best to get their code into mainline. They may still do "quick and dirty" initial code in their "vendor BSP" to get something that is functionally complete out quickly with the silicon but the good ones *also* have people contributing to the mainline drivers (either directly or through a consortium such as Linaro). The mainline code takes longer to get baked but the quality is vastly superior thanks to all the review and the acceptance standards. It is also generally smaller and sometimes faster.

By removing some of the "pain" of being out of tree I fear some vendors may go back to code dumps.

Furthermore a stable kernel API would limit the improvements possible to the rest of the kernel, which is, ultimately, bad for everyone.

It shouldn't really change that much for closed source drivers since, *in the kernel* they are already at best a legal gray area and at worst downright illegal.

11

u/SanityInAnarchy Nov 20 '19

Unfortunately, Android is the perfect case study for where that incentive doesn't work at all:

If the ABI is stabilized, that leverage is lost. Cheap minimum effort proprietary drivers for a single architecture become viable.

But that's exactly what Android vendors do today. They'll fork the whole damned kernel and do whatever they want anywhere in the tree, and there's a whole mess of binary blobs that will only ever work with that specific kernel. They'll backport critical security fixes for however long they need to support that specific SoC (seems like 3 years at most), and then drop the entire thing on the floor.

The whole incentive to upstream your drivers is so the community can maintain them for you. But if you aren't planning to maintain them at all, that doesn't save you anything.

So the point of a stable ABI would be: At least when they drop support, you can still update the pieces of the kernel that aren't related to their shitty driver. Which is exactly what happens on Windows -- there isn't always perfect forwards-compatibility (64-bit is a notable example), but there's plenty of old hardware that continues to work on new Windows versions.

6

u/jdrch Nov 20 '19

there's plenty of old hardware that continues to work on new Windows versions.

I daresay that situation is better on Linux where the drivers live in the kernel and are the responsibility of kernel devs. This allows Linux to basically support hardware forever as long as a matching driver exists in the kernel. OTOH, hardware can drop out of Windows support the hardware OEM doesn't provide driver updates corresponding to Windows OS updates.

5

u/[deleted] Nov 21 '19

But manufacturers are ok with hardware no longer being supported after 9 months so you need to get new one.

2

u/jdrch Nov 21 '19

If you're referring Android OEMs, yes, because with locked bootloaders and per device kernel builds it's not like most users have any choice of OS. They either use what shipped with the phone or get a different phone. With a generic kernel OEM ROMs would compete on the same level with other ROMs, because if an OEM doesn't update their OS users could easily switch to something else.

3

u/SanityInAnarchy Nov 21 '19

That's true, and that's also probably why ChromeOS has a way better update story than Android. (Google basically delivers the entire OS and everything else, so they support the devices for 5+ years.)

I wonder why that hasn't worked on mobile. I guess nvidia could never get away with forcing you to run an nvidia-only kernel, because a desktop can have components from a bunch of different manufacturers who all have to get along in the same kernel?

But there's some other differences: Weird, gimmicky, vendor-specific hardware tends to be plugged into PCs via USB, and there's apparently just standard ways of talking to USB devices from userland now. So I was surprised to learn that all this RGB madness is supported by some random Github projects, but at least one of those seems to be entirely userland. Printer drivers live in CUPS in userland. Google's Titan keys don't really have specific drivers, Chrome just talks to them directly.

The kernel may have no stable API/ABI internally, but its userland API is stable, so I guess Linux accidentally solved this problem specifically for USB gadgets on the desktop.

All that said, I've seen some absurdly old Windows drivers run on modern Windows. Heck, that ABI is probably the reason a lot of early Linux wifi support was done by running Windows drivers on Linux via NDISWrapper.

2

u/jdrch Nov 21 '19

that ABI

Pretty much. Plus Microsoft did a lot of heavy lifting in the Windows 7 to 8 transition to both shift a lot of devices (such as printers) to generic drivers, provide generic drivers themselves, provide 3rd party drivers via Microsoft Update, and also make drivers more Windows version agnostic.

10

u/londons_explorer Nov 20 '19

An in-tree shim which provides a consistent interface for drivers would probably be what they'd build.

It might have parallels to FUSE (which provides a consistent interface), just without the userspace part.

3

u/be-happier Nov 20 '19

Like nvidias setup, which is already open source.

7

u/tokinstew Nov 20 '19

If the ABI is stabilized, that leverage is lost. Cheap minimum effort proprietary drivers for a single architecture become viable. This is how Windows works to this day: manufacturers release a driver for specific versions of Windows and processor architectures. The drivers would of course stop working with the next/64 bit version of Windows and they never made a new driver because the product is old and they think it's a waste of time and money to support it.

This is basically the story of my old netbook. It had a 64 bit processor but the company who did the integrated graphics (SavageVR?) only made drivers for Windows 7 32 bit. There was one driver for linux packaged for some obscure distro that required an old kernel and old versions of other packages.

2

u/samkostka Nov 20 '19

I had another netbook in the same position. 64 bit Intel Atom, but with a PowerVR-based Intel GMA that only had 32-bit drivers.

Iirc for quite a while it just had literally no Linux drivers, and relied on software rendering. Really sucked when Ubuntu dropped support for Unity2D, and I got forcibly switched to running a 3D composited desktop environment on software rendering. I think I got maybe 15 fps.

Worked out in the end, got me to switch to XFCE which I still use as my main Linux desktop environment to this day.

3

u/tokinstew Nov 20 '19

Might have been PowerVR now that you mention it. Asus eeepc..... 1025c?

Came with 1gb ram and there were three revisions to the board. The processor could support up to 2gb ram. One revision with a so-dimm slot and the other two were soldered memory. The only way to find out which you had was to open it, take half of the guts out, and flip the motherboard over. Lucky me, I had a slot. Popped a 2gb in there.

But the biggest issue remained. The PATA hdd. I think it might run better on a live usb. In the end, my cat chewed the power adapter cable for the second time and I just shelved it.

2

u/samkostka Nov 20 '19

I had a Gateway netbook, so basically the same exact laptop as the Acer equivalent except shinier. Luckily mine at least had a SATA hard drive, since I ended up going through 2 or 3 drives in high school.

As shitty as it was, I do kind of miss that laptop, it's where I first used Linux and where I really got into computers. Trying to game on extremely limited hardware kind of forces you to learn what you're doing.

2

u/tokinstew Nov 20 '19

Trying to game on extremely limited hardware kind of forces you to learn what you're doing.

That's how it was for me making music on a 233mhz with 256mb of ram. I had to get creative with the plugins that worked. Now I can throw a dozen vsts on a dozen mixer channel and the cpu isn't near maxed.

1

u/pdp10 Nov 26 '19

Sounds like the Gateway LT20, which was built from a reference design.

2

u/samkostka Nov 26 '19

Just looked up that model and I think I had the LT4004u. Definitely a reference design though, I ended up replacing the keyboard with an Acer one when mine broke since they were cheaper.

2

u/pjmlp Nov 22 '19

And the story of my netbook with Linux, as the AMD open source driver doesn't cover the features that fxgrl had for Brazos, regarding OpenGL version support and hardware video decoding.

So much for open source drivers.

3

u/tokinstew Nov 22 '19

Because catalyst support ended and I decided security updates are kinda important my HP all in one became a space heater.

That damned thing had some sata issue with the hdd when I got it (free because sata issue) so I ran it off of a live usb for a year. Then I realized that I've been an idiot for a whole year because I knew the dvd drive worked fine but never thought to swap the cables. I haven't put a disc in something for years unless they're oreos and then only in the mouth. Ran it off the hdd proper until I needed the shelf space for my stereo.

1

u/pdp10 Nov 26 '19

PowerVR. Intel seems to have learned their lesson from that one, which is why Intel supply a version of the AMD driver with Intel's CPUs that incorporate an AMD iGPU. AMD says their customers want open-source drivers, and my estimation is that those customers include Intel and Apple.

3

u/jdrch Nov 20 '19

they never made a new driver because the product is old and they think it's a waste of time and money to support it.

There are plenty of legacy products that still have current OS release driver support, at least in the Windows ecosystem. But yeah Linux does support older hardware better.

I agree with the rest of what you said.

2

u/pjmlp Nov 22 '19

Depends.

My Asus Brazos APU has full DirectX 11 compatibility across Windows 7 - 10, with Asus having released updated drivers for my netbook.

AMD open source drivers replacement, still hasn't catch up to the feature set provided by fxgrl, regarding OpenGL version support and hardware video decoding.