The end of CONFIG_ANDROID [LWN.net]

The end of CONFIG_ANDROID

Posted Jul 5, 2022 2:23 UTC (Tue) by pabs (subscriber, #43278)
Parent article: The end of CONFIG_ANDROID

Now that there are mobile devices running Linux based non-Android distros and people using them that probably want frequent suspends to reduce power usage there but the corresponding distros won't be enabling CONFIG_PM_USERSPACE_AUTOSLEEP in their main builds that are used on desktops and servers, does that mean distros need a second Linux kernel build just for mobile devices that want the behaviour?

It seems like runtime configuration of this behaviour, or simply the automatic handling of too-frequent suspends proposed in comments above, are the more correct solutions to this problem.

The end of CONFIG_ANDROID

Posted Jul 5, 2022 14:37 UTC (Tue) by zx2c4 (subscriber, #82519) [Link] (2 responses)

> It seems like runtime configuration of this behaviour, or simply the automatic handling of too-frequent suspends proposed in comments above, are the more correct solutions to this problem.

I suggested a runtime configuration knob and wrote a patch for it, but the Android developers didn't want to add new ABI and felt a compile time knob would be sufficient. It didn't really make a difference to me, so I said okay, and wrote a sample patch for a compile time knob too. But if somebody else has an expanded use case, this is a pretty darn easy thing to change into a runtime switch later.

As for your repeating of Corbet's comment that this is handled automatically, see https://lore.kernel.org/wireguard/CAHmME9p2OYSTX2C5M0faKt... for a thread where somebody asked the same thing, and we took it to its logical conclusion which is having laptops wake up in backpacks. If you have better ideas, though, feel free to reply on that mailing list and I'd be very happy to consider good alternatives.

The end of CONFIG_ANDROID

Posted Jul 5, 2022 14:56 UTC (Tue) by pabs (subscriber, #43278) [Link] (1 responses)

I think you have misinterpreted the suggestion in the second last post in the thread. They were not suggesting that expiry of the time period cause wakeups, but instead that when something else caused a wakeup, then before using the keys again, check if the minimum time has passed and do the key expiry and renegotiation then. Doing it that way would not cause laptops to wake up in backpacks. This does mean that keys stay around across suspend and maybe that is not desirable though?

The end of CONFIG_ANDROID

Posted Jul 5, 2022 14:59 UTC (Tue) by zx2c4 (subscriber, #82519) [Link]

> This does mean that keys stay around across suspend and maybe that is not desirable though?

Yes. You're repeating the same exercise as the thread I just linked.

One Kernel For All

Posted Jul 11, 2022 15:34 UTC (Mon) by fratti (subscriber, #105722) [Link] (1 responses)

> Now that there are mobile devices running Linux based non-Android distros and people using them that probably want frequent suspends to reduce power usage there but the corresponding distros won't be enabling CONFIG_PM_USERSPACE_AUTOSLEEP in their main builds that are used on desktops and servers, does that mean distros need a second Linux kernel build just for mobile devices that want the behaviour?

I don't see an issue in requiring distros that ship mobile GUI frontends to also ship their own kernel. You probably already don't want to ship your server's kernel (see preemption settings) and you're going to be shipping completely different images for desktop vs. ARM handset already anyway. Asking a distro to have a second kernel package for an entirely different class of device really isn't that big of a deal, especially when said kernel likely needs certain things for powersaving and Android compatibility tuned for it.

For what it's worth, my experience in the ARM ecosystem is that we'll never get to have one kernel that fits all use cases there simply due to all the erratas and different device requirements.

One Kernel For All

Posted Jul 12, 2022 1:20 UTC (Tue) by pabs (subscriber, #43278) [Link]

We are already there for 64-bit ARM and 32-bit ARMv7, distros only ship one mainline Linux kernel image for all devices. Of course for non-mainline devices its a different situation, you need one Linux kernel image per device, but most generic distros outside the hardware-specific distros do not support non-mainline devices.

I very much doubt distros would add a mobile variant just for one config option. Distros do not want to have multiple images for different use-cases, they want one Linux kernel image that boots on any hardware and works for any use-case. I think they might accept a boot-time option though if automatic behaviour selection at boottime or runtime really isn't going to be implemented, a boot option is still a bit of a hack though.

At least that is the situation for Debian arm64 and armhf. For arm64 it has a single image for devices and also a -cloud image that contains a cut-down image with only cloud related config to reduce the image size and boot time. For armhf Debian ships two "multiplatform" kernel flavours; with and without LPAE. Also -rt images for both because RT isn't able to be enabled/disabled at boot or runtime.

https://www.debian.org/releases/stable/arm64/ch02s01.en.h...
https://wiki.debian.org/DebianKernel/ARMMP

$ apt-cache showsrc linux-signed-arm64 | grep '^ linux-image'
linux-image-5.18.0-2-arm64 deb kernel optional arch=arm64
linux-image-5.18.0-2-cloud-arm64 deb kernel optional arch=arm64
linux-image-5.18.0-2-rt-arm64 deb kernel optional arch=arm64
linux-image-arm64 deb kernel optional arch=arm64
linux-image-cloud-arm64 deb kernel optional arch=arm64
linux-image-rt-arm64 deb kernel optional arch=arm64
$ apt-cache showsrc linux | grep 'arch=armhf' | grep '^ linux-image' | grep -v -- '-dbg'
linux-image-5.18.0-2-armmp deb kernel optional arch=armhf profile=!pkg.linux.nokernel,!pkg.linux.quick,!stage1
linux-image-5.18.0-2-armmp-lpae deb kernel optional arch=armhf profile=!pkg.linux.nokernel,!pkg.linux.quick,!stage1
linux-image-5.18.0-2-rt-armmp deb kernel optional arch=armhf profile=!pkg.linux.nokernel,!pkg.linux.quick,!stage1
linux-image-armmp deb kernel optional arch=armhf profile=!pkg.linux.nokernel,!pkg.linux.nometa,!pkg.linux.quick,!stage1
linux-image-armmp-lpae deb kernel optional arch=armhf profile=!pkg.linux.nokernel,!pkg.linux.nometa,!pkg.linux.quick,!stage1
linux-image-rt-armmp deb kernel optional arch=armhf profile=!pkg.linux.nokernel,!pkg.linux.nometa,!pkg.linux.quick,!stage1