Google's Gasket Driver Framework Landing For Linux 4.19

[Weasel]

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.

Doesn't this make it "slow", like FUSE is, with a lot of overhead? Kernel code has the advantage of no privilege or context switches.

[starshipeleven]

Doesn't this make it "slow", like FUSE is, with a lot of overhead?

Theoretically, yes. I don't know how much this actually matters in practice, in products where there is some large force developing them.

I mean, Android has like 3 levels of abstraction (different APIs between system components and apps) before something can even reach the actual blob driver to do something basic like media acceleration.

And it's using a custom JavaVM to run the show. And is locked down so everything an application does requires more resources to check its permissions and provide a secure handle or something, and has a ton of tracking going on all the time (ads you know).

But usually it isn't really running like total trash unless you buy Samsung phones (their "Lagwiz" interface is legendary, it can put even their flagship phone on its knees).

So I wouldn't be surprised if at the end of the day the performance hit will be detectable but not significant.

[oiaohm]

Doesn't this make it "slow", like FUSE is, with a lot of overhead? Kernel code has the advantage of no privilege or context switches.

You have to remember fuse has roughly userspace application -> kernel space->fuse userspace-> kernel space-> userspace application.

https://www.infoworld.com/article/3189664/networking/sdn-dilemma-linux-kernel-networking-vs-kernel-bypass.html

Networking stack bipasses are a lot like google gasket. Also gasket are a lot like pci pass though for virtual machines. So not that heavy of a overhead.

Please note google gasket driver has to be better than samsung being caught putting /dev/mem under a different name.

https://forum.xda-developers.com/showthread.php?t=2048511

Yes the /dev/exynos-mem security hole. Because they wanted to write their drivers in user-space.

Please note samsung was not the only android device maker caught doing things this insane.

https://lwn.net/Articles/754449/

Really I find bpf being used in drivers more interesting. As bpf jit is native inside the Linux kernel itself. So only adds some driver start up overhead. Does have me asking a question how much of driver operation could be written in bpf restricted language.

[pal666]

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.

google can't outcompete linux kernel. they are not even largest contributor. even microsoft openly admits it can't outcompete linux kernel

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.

so it will be hugely successful like hurd?

[Weasel]

You have to remember fuse has roughly userspace application -> kernel space->fuse userspace-> kernel space-> userspace application.

Thanks for the info, do you have the source for this? I'd like to read it, because I want to see *why* it has to do it that way, it sounds dumb as hell but maybe I'm (clearly) overlooking something here...

[Britoid]

google can't outcompete linux kernel. they are not even largest contributor. even microsoft openly admits it can't outcompete linux kernel
so it will be hugely successful like hurd?

For Android/ChromeOS they don't need to.

Thanks for the info, do you have the source for this? I'd like to read it, because I want to see *why* it has to do it that way, it sounds dumb as hell but maybe I'm (clearly) overlooking something here...

App creates syscall (asks the kernel) to open file ( Userland- > Kernel )
Kernel maps file to driver, which is generic fuse driver, which it turn asks the userland driver (Kernel -> Userland)
Userland driver (e.g. NTFS-3G) gets the file lookup, there may be multiple swaps between the fuse driver and userland driver here, and ultimately returns the file to the fuse driver ( Userland -> Kernel)
Kernel sends the file to the app. (Kernel -> Userland )


In-kernel drivers don't do this. But you have to implement the driver in kernel-space.

[Weasel]

App creates syscall (asks the kernel) to open file ( Userland- > Kernel )
Kernel maps file to driver, which is generic fuse driver, which it turn asks the userland driver (Kernel -> Userland)
Userland driver (e.g. NTFS-3G) gets the file lookup, there may be multiple swaps between the fuse driver and userland driver here, and ultimately returns the file to the fuse driver ( Userland -> Kernel)
Kernel sends the file to the app. (Kernel -> Userland )

But the first and last points should be excluded because they happen without FUSE too. I don't see what's the point in including them?

So without those it's only an extra 2-way communication, not 4 times more as before.

Furthermore, any userspace drivers (from micro kernel) will do the exact same thing if it's implemented with syscalls. Unless it's implemented with some sort of library only (removing the first and last steps), which is probably what you guys meant right?

[oiaohm]

Furthermore, any userspace drivers (from micro kernel) will do the exact same thing if it's implemented with syscalls. Unless it's implemented with some sort of library only (removing the first and last steps), which is probably what you guys meant right?

Except microkernels do not function the same. Most microkernels use IPC a lot more than syscalls. IPC sometimes allows userland driver running on one cpu to be using message bus to talk to application running on a different cpu without passing though kernel space in micro kernels.

Microkernels use ipc message bus way more than syscalls.

But the first and last points should be excluded because they happen without FUSE too. I don't see what's the point in including them?

Except once a gasket driver is set up or a network stack bipass driver is set up you are not needing to switch to kernel space to perform every task. This is why those can be higher performing than kernel mode drivers at times. So first and last points happen without fuse always is wrong. Those happen first and last points happen it s a kernel mode driver or pretending to be a kernel mode driver. Absolutely pure user-space driver with memory mapped and setup by kernel at start does not have to switch from kernel to userspace and back at all if it design to exploit a userspace IPC like microkernels do that functions without switching though kernel. Yes network stack bipasses on Linux different ones use userspace only IPC so that the userspace network space can be running in usermode on particular cores and respond to applications running on other cores without overhead of switching to kernel mode and back(does pick on the MMU ).


Basically a proper microkernel style driver could be done with gasket on the Linux kernel and those drivers avoid switching to kernel unless it required. So gasket might not be that slow.

[Weasel]

Except microkernels do not function the same. Most microkernels use IPC a lot more than syscalls. IPC sometimes allows userland driver running on one cpu to be using message bus to talk to application running on a different cpu without passing though kernel space in micro kernels.

Microkernels use ipc message bus way more than syscalls.

IPC is just as bad, if not even worse, than pure syscalls though...? But yeah you have a point with most of the driver implemented in userland, that's why I mentioned it as the possible reason being faster than FUSE.

[oiaohm]

IPC is just as bad, if not even worse, than pure syscalls though...? But yeah you have a point with most of the driver implemented in userland, that's why I mentioned it as the possible reason being faster than FUSE.

It depends on the type of IPC how bad it is. Shared memory IPC avoided need to context switch other than to set it up. On multi core systems you are exploiting mmu to copy data.

https://blog.linuxplumbersconf.org/2016/ocw//system/presentations/4185/original/LPC%20HWC%202.0%20&%20drm_hwcomposer%20.pdf

Next if you call IPC bad android is bad. Surface finger to hardware compositor on Android is IPC. OpenGL ES can also be implemented on top of IPC on Android devices in fact Android binary only graphics drivers are meant to be implemented this way and libhybris supported using those drivers under normal Linux.

Yes the reason why samsung and other want to do usermode drivers for android is to avoid syscall overhead. IPC overhead is part of the Android API/ABI. With the prior goof ups with security those wanting to userspace drivers for Android need a safe way to-do it.

So there is a context thing. If you have to-do IPC anyhow avoid syscalls can have benefit.