On Wed, Dec 11, 2019 at 2:31 AM Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx> wrote: > I don't consider users of non-vanilla kernels to necessarily be a > reason to merge patches upstream, no. They carry literally millions > of lines of patches out of tree, let them carry this patch, too. > If I can't boot a vanilla kernel on those devices, and clearly there is > no intent by the device manufacturers for me to ever will, why would I > care? That's *not* the intent. https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/ > > The reason Android runs non-vanilla kernels is *because* patches like > > this - that make Linux work in the real world - are missing from > > vanilla Linux That's exactly the point here. Saying, "Android will never use mainline, so why should mainline take their patches" is a self-fulfilling prophecy. Obviously, if mainline never takes Android patches, then yes, Android will never be able to use mainline. We do have an Android tree we can take this patch into. But we don't want to take it without at least attempting to get it into mainline first. The use case here is pretty simple. There are many CPUs in a mobile phone. The baseband processor ("modem") implements much of the functionality required by cellular networks, so if you want cellular voice or data, it needs to be able to talk to the network. For many reasons (architectural, power conservation, security), the modem needs to be able to talk directly to the cellular network. This includes, for example, SIP/RTP media streams that go directly to the audio hardware, IKE traffic that is sent directly by the modem because only the modem has the keys, etc. Normally this happens directly on the cellular interface and Linux/Android is unaware of it. But, when using wifi calling (which is an IPsec tunnel over wifi to an endpoint inside the cellular network), the device only has one IPv4 address, and the baseband processor and the application processor (the CPU that runs Linux/Android) have to share it. This means that some ports have to be reserved so that the baseband processor can depend on using them. NAT cannot be used because the 3GPP standards require protocols that are not very NAT-friendly, and because the modem needs to be able to accept unsolicited inbound traffic. Other than "commit message doesn't have a use case", are there technical concerns with this patch?
