Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1591485 > unrolled thread
| Started by | Laura Abbott <labbott@redhat.com> |
|---|---|
| First post | 2017-03-02 22:50 +0100 |
| Last post | 2017-03-03 20:20 +0100 |
| Articles | 6 on this page of 66 — 14 participants |
Back to article view | Back to linux.kernel
[RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 01/12] staging: android: ion: Remove dmap_cnt Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 17:50 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laura Abbott <labbott@redhat.com> - 2017-03-03 20:00 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 11:50 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-06 14:50 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 17:00 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laura Abbott <labbott@redhat.com> - 2017-03-06 20:30 +0100
[RFC PATCH 09/12] cma: Introduce cma_for_each_area Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 03/12] staging: android: ion: Duplicate sg_table Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2017-03-03 09:40 +0100
Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table Laura Abbott <labbott@redhat.com> - 2017-03-03 19:50 +0100
[RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 16:10 +0100
Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable Laura Abbott <labbott@redhat.com> - 2017-03-03 20:50 +0100
[RFC PATCH 05/12] staging: android: ion: Remove page faulting support Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 02/12] staging: android: ion: Remove alignment from allocation field Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Dan Carpenter <dan.carpenter@oracle.com> - 2017-03-03 12:10 +0100
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Eric Engestrom <eric.engestrom@imgtec.com> - 2017-03-03 13:00 +0100
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 17:40 +0100
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Laura Abbott <labbott@redhat.com> - 2017-03-03 19:50 +0100
[RFC PATCH 07/12] staging: android: ion: Remove old platform support Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 07/12] staging: android: ion: Remove old platform support Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 11:40 +0100
[RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 11:00 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 18:00 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laura Abbott <labbott@redhat.com> - 2017-03-03 19:50 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 11:50 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Emil Velikov <emil.l.velikov@gmail.com> - 2017-03-06 18:40 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laura Abbott <labbott@redhat.com> - 2017-03-06 20:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 11:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 11:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-03-03 15:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 17:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-03 20:20 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 11:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-06 16:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 17:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Michal Hocko <mhocko@kernel.org> - 2017-03-03 14:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-03 18:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Michal Hocko <mhocko@kernel.org> - 2017-03-06 09:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 12:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Mark Brown <broonie@kernel.org> - 2017-03-06 12:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 17:20 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-03-09 11:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-09 19:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Brian Starkey <brian.starkey@arm.com> - 2017-03-10 11:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Robin Murphy <robin.murphy@arm.com> - 2017-03-10 12:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Brian Starkey <brian.starkey@arm.com> - 2017-03-10 15:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-10 17:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-10 13:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Rob Clark <robdclark@gmail.com> - 2017-03-10 15:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-03-12 14:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel.vetter@ffwll.ch> - 2017-03-12 20:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-13 22:20 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Rob Clark <robdclark@gmail.com> - 2017-03-13 22:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-13 23:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Brian Starkey <brian.starkey@arm.com> - 2017-03-13 12:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Mark Brown <broonie@kernel.org> - 2017-03-13 14:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-13 22:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-13 22:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Michal Hocko <mhocko@kernel.org> - 2017-03-06 14:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 17:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-03 20:20 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2017-03-13 14:30 +0100 |
| Subject | Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging |
| Message-ID | <tkycW-176-21@gated-at.bofh.it> |
| In reply to | #1599206 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote: > On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: > > Another point is how can we put secure rules (like selinux policy) on > > heaps since all the allocations > > go to the same device (/dev/ion) ? For example, until now, in Android > > we have to give the same > > access rights to all the process that use ION. > > It will become problem when we will add secure heaps because we won't > > be able to distinguish secure > > processes to standard ones or set specific policy per heaps. > > Maybe I'm wrong here but I have never see selinux policy checking an > > ioctl field but if that > > exist it could be a solution. > I might be thinking of a different type of "secure", but... > Should the security of secure heaps be enforced by OS-level > permissions? I don't know about other architectures, but at least on > arm/arm64 this is enforced in hardware; it doesn't matter who has > access to the ion heap, because only secure devices (or the CPU > running a secure process) is physically able to access the memory > backing the buffer. > In fact, in the use-cases I know of, the process asking for the ion > allocation is not a secure process, and so we wouldn't *want* to > restrict the secure heap to be allocated from only by secure > processes. I think there's an orthogonal level of OS level security that can be applied here - it's reasonable for it to want to say things like "only processes that are supposed to be implementing functionality X should be able to try to allocate memory set aside for that functionality". This mitigates against escallation attacks and so on, it's not really directly related to secure memory as such though.
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-13 22:50 +0100 |
| Subject | Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging |
| Message-ID | <tkG0O-6MV-25@gated-at.bofh.it> |
| In reply to | #1599360 |
On 03/13/2017 06:21 AM, Mark Brown wrote: > On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote: >> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: > >>> Another point is how can we put secure rules (like selinux policy) on >>> heaps since all the allocations >>> go to the same device (/dev/ion) ? For example, until now, in Android >>> we have to give the same >>> access rights to all the process that use ION. >>> It will become problem when we will add secure heaps because we won't >>> be able to distinguish secure >>> processes to standard ones or set specific policy per heaps. >>> Maybe I'm wrong here but I have never see selinux policy checking an >>> ioctl field but if that >>> exist it could be a solution. > >> I might be thinking of a different type of "secure", but... > >> Should the security of secure heaps be enforced by OS-level >> permissions? I don't know about other architectures, but at least on >> arm/arm64 this is enforced in hardware; it doesn't matter who has >> access to the ion heap, because only secure devices (or the CPU >> running a secure process) is physically able to access the memory >> backing the buffer. > 3 >> In fact, in the use-cases I know of, the process asking for the ion >> allocation is not a secure process, and so we wouldn't *want* to >> restrict the secure heap to be allocated from only by secure >> processes. > > I think there's an orthogonal level of OS level security that can be > applied here - it's reasonable for it to want to say things like "only > processes that are supposed to be implementing functionality X should be > able to try to allocate memory set aside for that functionality". This > mitigates against escallation attacks and so on, it's not really > directly related to secure memory as such though. > Ion also makes it pretty trivial to allocate large amounts of kernel memory and possibly DoS the system. I'd like to have as little policy in Ion as possible but more important would be a general security review and people shouting "bad idea ahead". Thanks, Laura
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-13 22:30 +0100 |
| Subject | Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging |
| Message-ID | <tkFHt-6Dq-33@gated-at.bofh.it> |
| In reply to | #1599206 |
On 03/13/2017 03:54 AM, Brian Starkey wrote: > On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: >> 2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott@redhat.com>: >>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>: >>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote: >>>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote: >>>>>> >>>>>>> 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. >>>>>> >>>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the >>>>>>> syncpt stuff. >>>>>> >>>>>> Well, there's also the fact that quite a few people have issues with the >>>>>> design (like Laurent). It seems like a lot of them have either got more >>>>>> comfortable with it over time, or at least not managed to come up with >>>>>> any better ideas in the meantime. >>>>> >>>>> See the TODO, it has everything a really big group (look at the patch for >>>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just >>>>> merge stuff because merging stuff is fun :-) >>>>> >>>>> Laurent was even in that group ... >>>>> -Daniel >>>> >>>> For me those patches are going in the right direction. >>>> >>>> I still have few questions: >>>> - since alignment management has been remove from ion-core, should it >>>> be also removed from ioctl structure ? >>> >>> Yes, I think I'm going to go with the suggestion to fixup the ABI >>> so we don't need the compat layer and as part of that I'm also >>> dropping the align argument. >>> >>>> - can you we ride off ion_handle (at least in userland) and only >>>> export a dma-buf descriptor ? >>> >>> Yes, I think this is the right direction given we're breaking >>> everything anyway. I was debating trying to keep the two but >>> moving to only dma bufs is probably cleaner. The only reason >>> I could see for keeping the handles is running out of file >>> descriptors for dma-bufs but that seems unlikely. >>>> >>>> In the future how can we add new heaps ? >>>> Some platforms have very specific memory allocation >>>> requirements (just have a look in the number of gem custom allocator in drm) >>>> Do you plan to add heap type/mask for each ? >>> >>> Yes, that was my thinking. >> >> My concern is about the policy to adding heaps, will you accept >> "customs" heap per >> platforms ? per devices ? or only generic ones ? >> If you are too strict, we will have lot of out-of-tree heaps and if >> you accept of of them >> it will be a nightmare to maintain.... >> > > Are you concerned about actual heaps (e.g. a carveout at 0x80000000 vs > a carveout at 0x60000000) or heap types? > > For heap types, I think the policy can be strict - if it's generally > useful then it should live in-tree in ion. Otherwise, it would be > out-of-tree. I'd expect most "custom" heaps to be parameterisable to > the point of being generally useful. > I'm willing to be reasonably permissive in what lives in tree. A good example would be something like a heap for the OMAP tiler which had weird hardware requirements. The associated devices that go with the heap should be well supported upstream though. > For actual heap instances, I would expect them to be communicated via > reserved-memory regions or something similar, and so the maintenance > burden is pretty low. > Yes. After the next round of review for this series I'm going to start thinking about properties for chunk and carveout heaps if nobody proposes something first. > The existing query ioctl can allow heap IDs to get assigned > dynamically at runtime, so there's no need to reserve "bit 6" for > "CUSTOM_ACME_HEAP_1" > >> Another point is how can we put secure rules (like selinux policy) on >> heaps since all the allocations >> go to the same device (/dev/ion) ? For example, until now, in Android >> we have to give the same >> access rights to all the process that use ION. >> It will become problem when we will add secure heaps because we won't >> be able to distinguish secure >> processes to standard ones or set specific policy per heaps. >> Maybe I'm wrong here but I have never see selinux policy checking an >> ioctl field but if that >> exist it could be a solution. >> > > I might be thinking of a different type of "secure", but... > > Should the security of secure heaps be enforced by OS-level > permissions? I don't know about other architectures, but at least on > arm/arm64 this is enforced in hardware; it doesn't matter who has > access to the ion heap, because only secure devices (or the CPU > running a secure process) is physically able to access the memory > backing the buffer. > > In fact, in the use-cases I know of, the process asking for the ion > allocation is not a secure process, and so we wouldn't *want* to > restrict the secure heap to be allocated from only by secure > processes. > > -Brian > >>> >>>>
[toc] | [prev] | [next] | [standalone]
| From | Michal Hocko <mhocko@kernel.org> |
|---|---|
| Date | 2017-03-06 14:40 +0100 |
| Subject | Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging |
| Message-ID | <ti11M-rk-1@gated-at.bofh.it> |
| In reply to | #1593193 |
On Mon 06-03-17 11:40:41, Daniel Vetter wrote: > On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote: > > On Fri 03-03-17 09:37:55, Laura Abbott wrote: > > > On 03/03/2017 05:29 AM, Michal Hocko wrote: > > > > On Thu 02-03-17 13:44:32, Laura Abbott wrote: > > > >> 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
[toc] | [prev] | [next] | [standalone]
| From | Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
|---|---|
| Date | 2017-03-03 17:30 +0100 |
| Message-ID | <tgYfE-3Kq-13@gated-at.bofh.it> |
| In reply to | #1591485 |
Hi Laura, Thank you for the patches. On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote: > 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. That's where most of my concerns with ion are. I still strongly believe that the heap-based approach is inherently flawed, as it would need to be configured for each device according to product-specific use cases. That's not something that could be easily shipped with a generic distribution. We should replace that with a constraint-based system. > - 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. > > Feedback appreciated. > > Thanks, > Laura > > [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2 > [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2 > > Laura Abbott (12): > staging: android: ion: Remove dmap_cnt > staging: android: ion: Remove alignment from allocation field > staging: android: ion: Duplicate sg_table > staging: android: ion: Call dma_map_sg for syncing and mapping > staging: android: ion: Remove page faulting support > staging: android: ion: Remove crufty cache support > staging: android: ion: Remove old platform support > cma: Store a name in the cma structure > cma: Introduce cma_for_each_area > staging: android: ion: Use CMA APIs directly > staging: android: ion: Make Ion heaps selectable > staging; android: ion: Enumerate all available heaps > > drivers/base/dma-contiguous.c | 5 +- > drivers/staging/android/ion/Kconfig | 51 ++-- > drivers/staging/android/ion/Makefile | 14 +- > drivers/staging/android/ion/hisilicon/Kconfig | 5 - > drivers/staging/android/ion/hisilicon/Makefile | 1 - > drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 --------- > drivers/staging/android/ion/ion-ioctl.c | 6 - > drivers/staging/android/ion/ion.c | 282 +++++------------- > drivers/staging/android/ion/ion.h | 5 +- > drivers/staging/android/ion/ion_carveout_heap.c | 16 +- > drivers/staging/android/ion/ion_chunk_heap.c | 15 +- > drivers/staging/android/ion/ion_cma_heap.c | 102 ++------ > drivers/staging/android/ion/ion_dummy_driver.c | 156 ------------ > drivers/staging/android/ion/ion_enumerate.c | 89 +++++++ > drivers/staging/android/ion/ion_of.c | 184 -------------- > drivers/staging/android/ion/ion_of.h | 37 --- > drivers/staging/android/ion/ion_page_pool.c | 3 - > drivers/staging/android/ion/ion_priv.h | 57 ++++- > drivers/staging/android/ion/ion_system_heap.c | 14 +- > drivers/staging/android/ion/tegra/Makefile | 1 - > drivers/staging/android/ion/tegra/tegra_ion.c | 80 ------ > include/linux/cma.h | 6 +- > mm/cma.c | 25 +- > mm/cma.h | 1 + > mm/cma_debug.c | 2 +- > 25 files changed, 312 insertions(+), 958 deletions(-) > delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig > delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile > delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c > delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c > create mode 100644 drivers/staging/android/ion/ion_enumerate.c > delete mode 100644 drivers/staging/android/ion/ion_of.c > delete mode 100644 drivers/staging/android/ion/ion_of.h > delete mode 100644 drivers/staging/android/ion/tegra/Makefile > delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c -- Regards, Laurent Pinchart
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-03 20:20 +0100 |
| Subject | Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging |
| Message-ID | <th0U9-5DA-5@gated-at.bofh.it> |
| In reply to | #1592111 |
On 03/03/2017 08:25 AM, Laurent Pinchart wrote: > Hi Laura, > > Thank you for the patches. > > On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote: >> 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. > > That's where most of my concerns with ion are. I still strongly believe that > the heap-based approach is inherently flawed, as it would need to be > configured for each device according to product-specific use cases. That's not > something that could be easily shipped with a generic distribution. We should > replace that with a constraint-based system. > I don't think of constraints and heaps as being mutually exclusive. Some general heaps (e.g. system heaps) can be available always. Others might just be exposed if there is a particular memory region available. The constraint solving is responsible for querying and figuring out what's the best choice. Thanks, Laura
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.kernel
csiph-web