Automatically build binder kernel modules as fallback

[agilgur5]

Motivation

Per #196 (comment), it seems like you're manually building the binder kernel modules to support Android/Waydroid whenever there's an update.

This requires manual, human intervention and more maintenance effort -- the most of any other piece of the codebase afaict¹ -- so I would suggest automating it.

Implementation Details

1. Instead, we could automatically build new ones with a GitHub Action cron schedule. This could check if a new version exists daily.

   • This is not currently possible due to lack of official SteamOS kernel release per below comments
   • Instead, we can fallback to building the module on device if a binary does not exist already

2. The binary could be uploaded to GH Releases as well in order to keep the repository more clean and free of built binaries

   • (repos are conventionally intended to only have source code ("source control"), and like the Linux kernel itself, should try to stay free of binary blobs (this is not always possible or preferable, however))
   • (dynamically downloading or linking dependencies also typically makes it easier to be compliant with licenses (i.e. Add a License #204 "Existing code and binaries") as opposed to distributing as part of the source repo)

3. The script could also check for the latest GH Release, meaning that users would not need to update their script if it's just for a binder module version update (if there are other changes, they might still need to). This is the most frequent reason an update is needed¹, so this should significantly reduce the maintenance burden.

   • to not require an internet connection, it can check the local filesystem if a binder module has already been downloaded first, and only if that doesn't match the version, try to download a newer one.

How to build?

I actually couldn't tell from the repo how you're building the binder kernel module, i.e. what commands you're specifically running.

From the modprobe command, I'm guessing you were following the "DKMS modules" route on the Arch Waydroid wiki (as linked to from the Waydroid install directions) and compiling the binder module alone, but I wasn't sure

Future Work

• Removing more of the binary blobs from the repo would also make it easier to package/distribute the script as a single file instead of a repo
  • similar to Package the Python scripts into a single executable binary for easy distribution casualsnek/waydroid_script#204
  • also would fulfill the OpenSSF Scorecard Check for "Binary Artifacts"

Footnotes

1. List of update issues: 6.5.0-valve23-1-neptune-65 kernel support #213, 6.5.0-valve22-1-neptune-65 is NOT supported #210, Can't install waydroid in steamos 3.6.20 #196, Kernel 6.5.0-valve23-1-neptune-65 is NOT supported. #194, kernel version NOT supported #183, Not supported (again) #181, SteamOs Update 11/5/2024 #179, Not supported  #175, Kernel not supported 6.5.0-valve22-1-neptune-65-g9a338ed8a75e #173, Kernel not supported  #171, Unable to install Waydroid due to unsupported Kernel #160, Missing bind for kernel 19-1 #158, unsupported kernel #149, etc ↩ ↩²

[agilgur5]

• Removing more of the binary blobs from the repo

Specifically referring to the pre-built binaries in waydroid/ and cage/ directories.
Regarding the waydroid/ deps, afaict, the blobs for lxc and dnsmasq shouldn't be necessary as they are non-AUR deps of waydroid and so should be auto-installed by pacman afaik (I haven't developed on Arch in a long time though...)

[ryanrudolfoba]

Initially the script does not contain prebuit binaries - it all depended on pacman and AUR to build them but this is more prone to error - example when pacman repos are out of sync. here is how it started

building from source also needs a lot of dependencies so ive decided to build and use prebuilt binaries.

for the binder module - i use the AUR and build from there. -

[agilgur5]

Thanks for the context Ryan!

building from source also needs a lot of dependencies so ive decided to build and use prebuilt binaries.

Yea I figure, that makes sense to simplify. Especially for end-users on Deck who may not care so much about having everything built on their host.

I would still suggest hosting prebuilt binaries either on GitHub Releases or via their own AUR packages (*-bin suffix ones may already exist even) so as to not have binary blobs in the source code itself and make updating binaries not necessarily require updating the script itself.

it all depended on pacman and AUR to build them but this is more prone to error - example when pacman repos are out of sync

For reference, you can install specific versions of packages with pacman, e.g. pacman -S package=1.2.3-1. That would mitigate versioning issues at least.
Per above though, pre-built binaries can certainly still be a better option in any case.

for the binder module - i use the AUR and build from there. -

Could you list the specific commands and specific AUR you use?
From the original commit you linked looks like it's binder_linux-dkms (per this line) as sourced from a fork of Anbox's kernel modules.
And then built with standard makepkg, more specifically makepkg --noconfirm -si -f.
Is that correct?

If I'm understanding correctly and that relies on your host having the appropriate version of SteamOS installed to be built against the kernel, then the option I proposed in #202 (comment) of using docker-steamos may not be sufficient for this specific task as the versions don't seem to be 1-to-1. Getting a 1-to-1 match of the Deck SteamOS version for testing/CI seems like it could be more challenging than I thought (especially without an official release from Valve) 😕
Although I'm not sure if the kernel module necessarily needs to be a 1-to-1 match on versioning, it depends on what changed in the kernel between the versions.

[agilgur5]

Although I'm not sure if the kernel module necessarily needs to be a 1-to-1 match on versioning, it depends on what changed in the kernel between the versions.

Ah, this is rarely the case with kernel modules and likely not for binder given its scope. Possible, but not probable. And it can't use eBPF instead of a kernel module either.

So auto-building specific kernel modules basically isn't really possible until Valve has an official kernel release (see also ValveSoftware/steamos_kernel#59). Until then, it basically requires someone to use their Deck since there is no other way to get a 1-to-1 release at the moment.

This requires manual, human intervention and more maintenance effort -- the most of any other piece of the codebase afaict1 -- so I would suggest automating it.

That being said, some of these benefits can be achieved by having there be a backup option that loads the module and compiles it via its sources if an exact match isn't available.

Falco's container is one I look to as an example of broad support for a kernel module, and indeed it looks like it downloads and compiles it on the fly

[ryanrudolfoba]

Could you list the specific commands and specific AUR you use?
From the original commit you linked looks like it's binder_linux-dkms (per this line) as sourced from a fork of Anbox's kernel modules.
And then built with standard makepkg, more specifically makepkg --noconfirm -si -f.
Is that correct?

Yes thats correct.

Once a new SteanOS beta gets released I'll try to update the script so it automatically builds the kernel module. It will install a few dependency but it will be fewer compared to when building waydroid from source. And once done remove those dependency so it's clean.

[agilgur5]

Once a new SteanOS [sic] beta gets released I'll try to update the script so it automatically builds the kernel module

Sounds good. I updated the issue title and "Implementation Details" section to list that the script can fallback/backup to build its own modules. I might write up a PR if I get to it first.

It will install a few dependency but it will be fewer compared to when building waydroid from source

Yea it only relies on dkms, although that does have some of its own dependencies, though I think most of those are pre-installed.
The kernel module is the most unstable piece since it's in, well, kernel space, whereas Waydroid and its extra APKs etc are (mostly?) in user space, so it makes the most sense to build it as part of the script compared to the rest too.

[slynobody]

had the same idea a while ago (#82). btw: what are the specific reasons to install manually precompiled lxc & dnsmasq (+ others) and not to rely on what steamos could deliver?

[ryanrudolfoba]

had the same idea a while ago (#82). btw: what are the specific reasons to install manually precompiled lxc & dnsmasq (+ others) and not to rely on what steamos could deliver?

Here -
#211 (comment)

And additionally so it is tied to a specific version. stable / beta contains different versions of lxx dnsmasq etc.