On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote:
On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote:
On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote:
The ION android code has long been marked to be removed, now that we dma-buf support merged into the real part of the kernel.
It was thought that we could wait to remove the ion kernel at a later time, but as the out-of-tree Android fork of the ion code has diverged quite a bit, and any Android device using the ion interface uses that forked version and not this in-tree version, the in-tree copy of the code is abandonded and not used by anyone.
Combine this abandoned codebase with the need to make changes to it in order to keep the kernel building properly, which then causes merge issues when merging those changes into the out-of-tree Android code, and you end up with two different groups of people (the in-kernel-tree developers, and the Android kernel developers) who are both annoyed at the current situation. Because of this problem, just drop the in-kernel copy of the ion code now, as it's not used, and is only causing problems for everyone involved.
Cc: "Arve Hjønnevåg" arve@android.com Cc: "Christian König" christian.koenig@amd.com Cc: Christian Brauner christian@brauner.io Cc: Christoph Hellwig hch@infradead.org Cc: Hridya Valsaraju hridya@google.com Cc: Joel Fernandes joel@joelfernandes.org Cc: John Stultz john.stultz@linaro.org Cc: Laura Abbott laura@labbott.name Cc: Martijn Coenen maco@android.com Cc: Shuah Khan shuah@kernel.org Cc: Sumit Semwal sumit.semwal@linaro.org Cc: Suren Baghdasaryan surenb@google.com Cc: Todd Kjos tkjos@android.com Cc: devel@driverdev.osuosl.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
We discussed this at the Android MC on Monday and the plan was to remove it after the next LTS release.
I know it was discussed, my point is that it is actually causing problems now (with developers who want to change the internal kernel api hitting issues, and newbies trying to clean up code in ways that isn't exactly optimal wasting maintainer cycles), and that anyone who uses this code, is not actually using this version of the code. Everyone who relies on ion right now, is using the version that is in the Android common kernel tree, which has diverged from this in-kernel way quite a bit now for the reason that we didn't want to take any of those new features in the in-kernel version.
So this is a problem that we have caused by just wanting to wait, no one is using this code, combined with it causing problems for the upstream developers.
There is nothing "magic" about the last kernel of the year that requires this code to sit here until then. At that point in time, all users will, again, be using the forked Android kernel version, and if we delete this now here, that fork can remain just fine, with the added benifit of it reducing developer workloads here in-kernel.
So why wait?
Hi,
I don't know what is the right thing to do here. I just want to highlight that AOSP's audio (codec2) HAL depends on the ION system heap and it will break AOSP for people who boot mainline on their devices, even for just testing purpose like we do in Linaro. Right now we need only 1 (Android specific out-of-tree) patch to boot AOSP with mainline and Sumit is already trying to upstream that vma naming patch. Removal of in-kernel ION, will just add more to that delta.
As AOSP will continue to rely on ION after December of this year, all you are doing is postponing the inevitable a few more months.
Push back on the Android team to fix up the code to not use ION, they know this needs to happen.
Hi all,
We are currently working with the codec2 team to transition codec2 to use libdmabufheap instead of libion. It will definitely happen during the Android S timeframe.
Thanks, Hridya
thanks,
greg k-h