[RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

On Mon 06-03-17 11:40:41, Daniel Vetter wrote:

On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote:

quoted

On Fri 03-03-17 09:37:55, Laura Abbott wrote:

quoted

On 03/03/2017 05:29 AM, Michal Hocko wrote:

quoted

On Thu 02-03-17 13:44:32, Laura Abbott wrote:

quoted

Hi,

There's been some recent discussions[1] about Ion-like frameworks. There's
apparently interest in just keeping Ion since it works reasonablly well.
This series does what should be the final clean ups for it to possibly be
moved out of staging.

This includes the following:
- Some general clean up and removal of features that never got a lot of use
  as far as I can tell.
- Fixing up the caching. This is the series I proposed back in December[2]
  but never heard any feedback on. It will certainly break existing
  applications that rely on the implicit caching. I'd rather make an effort
  to move to a model that isn't going directly against the establishement
  though.
- Fixing up the platform support. The devicetree approach was never well
  recieved by DT maintainers. The proposal here is to think of Ion less as
  specifying requirements and more of a framework for exposing memory to
  userspace.
- CMA allocations now happen without the need of a dummy device structure.
  This fixes a bunch of the reasons why I attempted to add devicetree
  support before.

I've had problems getting feedback in the past so if I don't hear any major
objections I'm going to send out with the RFC dropped to be picked up.
The only reason there isn't a patch to come out of staging is to discuss any
other changes to the ABI people might want. Once this comes out of staging,
I really don't want to mess with the ABI.

Could you recapitulate concerns preventing the code being merged
normally rather than through the staging tree and how they were
addressed?

Sorry, I'm really not understanding your question here, can you
clarify?

There must have been a reason why this code ended up in the staging
tree, right? So my question is what those reasons were and how they were
handled in order to move the code from the staging subtree.

No one gave a thing about android in upstream, so Greg KH just dumped it
all into staging/android/. We've discussed ION a bunch of times, recorded
anything we'd like to fix in staging/android/TODO, and Laura's patch
series here addresses a big chunk of that.

Thanks for the TODO reference. I was looking exactly at something like
that in drivers/staging/android/ion/. To bad I didn't look one directory
up.

Thanks for the clarification!

-- 
Michal Hocko
SUSE Labs