[PATCH 1/2] staging: android: ion: Remove file ion_carveout_heap.c

[John Stultz]

On Wed, Jul 3, 2019 at 4:32 AM Laura Abbott <labbott at redhat.com> wrote:
>
> On 7/3/19 5:50 AM, Daniel Vetter wrote:
> > On Wed, Jul 3, 2019 at 10:37 AM Greg KH <gregkh at linuxfoundation.org> wrote:
> >>
> >> On Wed, Jul 03, 2019 at 01:48:41PM +0530, Nishka Dasgupta wrote:
> >>> Remove file ion_carveout_heap.c as its functions and definitions are not
> >>> used anywhere.
> >>> Issue found with Coccinelle.
> >>>
> >>> Signed-off-by: Nishka Dasgupta <nishkadg.linux at gmail.com>
> >>> ---
> >>>   drivers/staging/android/ion/Kconfig           |   9 --
> >>>   drivers/staging/android/ion/Makefile          |   1 -
> >>>   .../staging/android/ion/ion_carveout_heap.c   | 133 ------------------
> >>
> >> I keep trying to do this, but others point out that the ion code is
> >> "going to be fixed up soon" and that people rely on this interface now.
> >> Well, "code outside of the kernel tree" relies on this, which is not ok,
> >> but the "soon" people keep insisting on it...
> >>
> >> Odds are I should just delete all of ION, as there hasn't been any
> >> forward progress on it in a long time.
> >>
> >> Hopefully that wakes some people up...
> >
> > John Stultz has done a steady stream on ion destaging patch series
> > past few months, und the heading of "DMA-BUF Heaps", targeting
> > drivers/dma-buf. I'm not following the details, and it seems a bit a
> > crawl, but there's definitely work going on ... Just probably not
> > in-place in staging I think.
> > -Daniel
> >
>
>
> https://lists.freedesktop.org/archives/dri-devel/2019-June/223705.html
>
> It is making slow and steady progress. Part of this is trying to
> make sure we actually get this right before moving anything
> out of staging.

Hopefully not too much longer. The review feedback has gotten quiet
recently so hopefully everyone is nodding.

Note, I'd also find it useful to *not* eject ION immediately after
dmabuf heaps land, since being able to do A/B validation on the same
kernel is useful if folks run into any new perf regressions. But
hopefully that transition time is fairly small.

> That said, I think we're at the point where nobody wants the
> carveout and chunk heaps so I'd actually be okay with removing
> those files. Just to be explicit:
>
> Acked-by: Laura Abbott <labbott at redhat.com>

Agreed. I think there are some out of tree uses by ARM and others for
the carveout heaps, but I don't know if anyone is using those
unmodified anyway.  So no objection from me, as there is no way to use
them upstream.

thanks
-john