On Wed, Jun 29, 2022 at 07:00:25PM +0200, Greg Kroah-Hartman wrote:
> I think that by the time the next kernel release comes out, and
> percolates to a real Android device, the years gone by will have caused
> those who care about this to fix it.

You assume that there aren't Android devices using kernels outside of
the ones you're referring to. That's a rather Google-centric
perspective. It's still breakage, even if Google has the ability to fix
it locally after "years gone by". If you want Android things to be
upstream, this is the way you must think about it; otherwise, what's the
point? By your logic, upstream should probably remove the Android code
everywhere and let Google handle it downstream. Except nobody wants
that; we want Android upstream. So let's keep it working upstream, not
intentionally break it.

> In the meantime, this might actually fix issues in desktop distros that
> were enabling this option, thinking it only affected the building of a
> driver

That sounds like a false dichotomy. It's not about "fix Android" vs "fix
distros". What I'm suggesting is fixing Android AND fixing distros, by
looking at the problem holistically. Trading a bad problem on Android
(wg connections are broken) for a manageable problem on distros (something
something theoretical warm boot attack something) doesn't sound like a
nice trade off. Let's instead get this all fixed at the same time.

> So it's nothing to worry about now, I agree with Christoph, this config
> option should not be used for power management policy decisions like
> this.  This should be controlled by userspace properly in the Android
> userspace framework, like all other Linux distros/systems do this.

Except right now it is. So if it's going to be removed, the code that
was depending on it will need to be updated coherently.

Jason

Reply via email to