Google's Gasket Driver Framework Landing For Linux 4.19

[phoronix]

Phoronix: Google's Gasket Driver Framework Landing For Linux 4.19

Queued into the staging code for introduction with the Linux 4.19 kernel is the Gasket driver framework and the first driver based upon it, Apex...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-Bringing-Gasket-Apex

[Guest]

So, reveal nothing useful in the GPLv2 code, and hide all of the important stuff in some proprietary user-space........wonderful, we absolutely need more of this everywhere. (sarcasm)

[ssokolow]

So, reveal nothing useful in the GPLv2 code, and hide all of the important stuff in some proprietary user-space........wonderful, we absolutely need more of this everywhere. (sarcasm)

More like "Move the proprietary gunk that was already being written into userspace so the kernel can be upgraded without waiting on a company that has already moved on to next year's model".

[Britoid]

I'm hoping that this eventually leads to something similar to Treble but for the kernel, all the device specific drivers and configuration that would go into kernel space can go into /vendor, as an alternative to a stable kernel ABI.

and devices can share the same kernel, which would solve one update issue.

[starshipeleven]

I'm hoping that this eventually leads to something similar to Treble but for the kernel, all the device specific drivers and configuration that would go into kernel space can go into /vendor, as an alternative to a stable kernel ABI.

and devices can share the same kernel, which would solve one update issue.

Kinda yes, but technically here the "drivers" (in the sense of Linux kernel modules) are in fact little more than shims for a userspace application/library where most of the driver actually is.

I'm NOT ok with letting garbage code (mobile drivers and embedded in general have total shit code quality) in kernel space, as it would mean an unstable system.

I'm also not ok with closed source code running in Linux kernel space.

I'm kinda ok with Gasket as it fulfills the above requirements, but I don't like where this is going.

[ermo]

I'm kinda ok with Gasket as it fulfills the above requirements, but I don't like where this is going.

One has to wonder if this is Google's way of preparing for a Fuchsia OS based future. Write a GASKET shim for both Linux and Fuchsia. Write in-house drivers for GASKET. Test and improve under both Linux and Fuchsia, rinse and repeat.

End result? Be kernel-agnostic and leave Linux behind when Fuchsia is ready. It's worth noting that Linux is coming up on 30 years old. With Fuchsia, drivers will likely live in user-space to a large degree, since it's a microkernel-based OS.

In essence, GASKET adds microkernel-ish veneer to Linux, sort of.

[nanonyme]

One has to wonder if this is Google's way of preparing for a Fuchsia OS based future. Write a GASKET shim for both Linux and Fuchsia. Write in-house drivers for GASKET. Test and improve under both Linux and Fuchsia, rinse and repeat.

End result? Be kernel-agnostic and leave Linux behind when Fuchsia is ready. It's worth noting that Linux is coming up on 30 years old. With Fuchsia, drivers will likely live in user-space to a large degree, since it's a microkernel-based OS.

In essence, GASKET adds microkernel-ish veneer to Linux, sort of.

Linus has also historically not been okay with having kernel drivers with no opensource userspace counterpart

[ermo]

Linus has also historically not been okay with having kernel drivers with no opensource userspace counterpart

For the sake of argument, let's say that Google isn't planning on upstreaming all of its drivers -- just the GASKET layer.

Is anything stopping Google from keeping its drivers in-house (possibly contributing a set of open-source reference drivers for some simple bits of kit) and then maintaining/relying on the upstream GASKET code in its in-house projects?

Would Linus' opinion even be of relevance in this scenario, given that GASKET represents a relatively minuscule code footprint and no extra maintenance burden? The GASKET stuff will likely be leveraged primarily by Android and Chrome OS anyway?

[F.Ultra]

For the sake of argument, let's say that Google isn't planning on upstreaming all of its drivers -- just the GASKET layer.

Is anything stopping Google from keeping its drivers in-house (possibly contributing a set of open-source reference drivers for some simple bits of kit) and then maintaining/relying on the upstream GASKET code in its in-house projects?

Would Linus' opinion even be of relevance in this scenario, given that GASKET represents a relatively minuscule code footprint and no extra maintenance burden? The GASKET stuff will likely be leveraged primarily by Android and Chrome OS anyway?

No, this is how nVIDIA and AMD maintain their closed drivers

edit: Sorry, misread your posts, thought that you meant that Google would maintain the GASKET layer inhouse and not upstream. No, Linus would probably not allow a layer like that since the only reason for it would be to be able to break the license of the kernel. But who lives will see I guess.

[starshipeleven]

In essence, GASKET adds microkernel-ish veneer to Linux, sort of.

Yeah, so we can see if going that route means what I think it means (vendors stop even pretending about caring about opensource drivers that do have quality standards to be accepted upstream and only publish low-quality rushed hacks of a driver) or not.

As I said, I'm not 100% against this as I see what is the landscape outside of PC hardware, as long as the driver is indeed a self-sufficient module (aka not like NVIDIA driver that will break hard if you change kernel of Xorg or whatever) AND is also running in userspace so crashing won't pull down the kernel with it.