From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752557AbdCNOtc (ORCPT ); Tue, 14 Mar 2017 10:49:32 -0400 Received: from mail-qk0-f169.google.com ([209.85.220.169]:35372 "EHLO mail-qk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751094AbdCNOr4 (ORCPT ); Tue, 14 Mar 2017 10:47:56 -0400 MIME-Version: 1.0 In-Reply-To: <6d3d52ba-29a9-701f-2948-00ce28282975@redhat.com> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <20170303132949.GC31582@dhcp22.suse.cz> <20170306074258.GA27953@dhcp22.suse.cz> <20170306104041.zghsicrnadoap7lp@phenom.ffwll.local> <20170306105805.jsq44kfxhsvazkm6@sirena.org.uk> <20170306160437.sf7bksorlnw7u372@phenom.ffwll.local> <26bc57ae-d88f-4ea0-d666-2c1a02bf866f@redhat.com> <6d3d52ba-29a9-701f-2948-00ce28282975@redhat.com> From: Benjamin Gaignard Date: Tue, 14 Mar 2017 15:47:54 +0100 Message-ID: Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging To: Laura Abbott Cc: Daniel Vetter , Mark Brown , Michal Hocko , Sumit Semwal , Riley Andrews , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Rom Lemarchand , devel@driverdev.osuosl.org, Linux Kernel Mailing List , "linaro-mm-sig@lists.linaro.org" , Greg Kroah-Hartman , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Brian Starkey , Daniel Vetter , Linux MM Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-03-13 22:09 GMT+01:00 Laura Abbott : > On 03/12/2017 12:05 PM, Daniel Vetter wrote: >> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard >> wrote: >>> 2017-03-09 18:38 GMT+01:00 Laura Abbott : >>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter : >>>>>> 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.... >> >> I think ion should expose any heap that's also directly accessible to >> devices using dma_alloc(_coherent). That should leave very few things >> left, like your SMA heap. >> >>> 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. >> >> Hm, we might want to expose all the heaps as individual >> /dev/ion_$heapname nodes? Should we do this from the start, since >> we're massively revamping the uapi anyway (imo not needed, current >> state seems to work too)? >> -Daniel >> > > I thought about that. One advantage with separate /dev/ion_$heap Should we use /devi/ion/$heap instead of /dev/ion_$heap ? I think it would be easier for user to look into one directory rather then in whole /dev to find the heaps > is that we don't have to worry about a limit of 32 possible > heaps per system (32-bit heap id allocation field). But dealing > with an ioctl seems easier than names. Userspace might be less > likely to hardcode random id numbers vs. names as well. In the futur I think that heap type will be replaced by a "get caps" ioctl which will describe heap capabilities. At least that is my understanding of kernel part of "unix memory allocator" project > > Thanks, > Laura From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f199.google.com (mail-qt0-f199.google.com [209.85.216.199]) by kanga.kvack.org (Postfix) with ESMTP id 5EF506B0038 for ; Tue, 14 Mar 2017 10:47:56 -0400 (EDT) Received: by mail-qt0-f199.google.com with SMTP id n37so65157872qtb.7 for ; Tue, 14 Mar 2017 07:47:56 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com. [2607:f8b0:400d:c09::234]) by mx.google.com with ESMTPS id v91si3150241qte.144.2017.03.14.07.47.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 07:47:55 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id y76so249541505qkb.0 for ; Tue, 14 Mar 2017 07:47:55 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <6d3d52ba-29a9-701f-2948-00ce28282975@redhat.com> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <20170303132949.GC31582@dhcp22.suse.cz> <20170306074258.GA27953@dhcp22.suse.cz> <20170306104041.zghsicrnadoap7lp@phenom.ffwll.local> <20170306105805.jsq44kfxhsvazkm6@sirena.org.uk> <20170306160437.sf7bksorlnw7u372@phenom.ffwll.local> <26bc57ae-d88f-4ea0-d666-2c1a02bf866f@redhat.com> <6d3d52ba-29a9-701f-2948-00ce28282975@redhat.com> From: Benjamin Gaignard Date: Tue, 14 Mar 2017 15:47:54 +0100 Message-ID: Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: Daniel Vetter , Mark Brown , Michal Hocko , Sumit Semwal , Riley Andrews , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Rom Lemarchand , devel@driverdev.osuosl.org, Linux Kernel Mailing List , "linaro-mm-sig@lists.linaro.org" , Greg Kroah-Hartman , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Brian Starkey , Daniel Vetter , Linux MM 2017-03-13 22:09 GMT+01:00 Laura Abbott : > On 03/12/2017 12:05 PM, Daniel Vetter wrote: >> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard >> wrote: >>> 2017-03-09 18:38 GMT+01:00 Laura Abbott : >>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter : >>>>>> 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.... >> >> I think ion should expose any heap that's also directly accessible to >> devices using dma_alloc(_coherent). That should leave very few things >> left, like your SMA heap. >> >>> 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. >> >> Hm, we might want to expose all the heaps as individual >> /dev/ion_$heapname nodes? Should we do this from the start, since >> we're massively revamping the uapi anyway (imo not needed, current >> state seems to work too)? >> -Daniel >> > > I thought about that. One advantage with separate /dev/ion_$heap Should we use /devi/ion/$heap instead of /dev/ion_$heap ? I think it would be easier for user to look into one directory rather then in whole /dev to find the heaps > is that we don't have to worry about a limit of 32 possible > heaps per system (32-bit heap id allocation field). But dealing > with an ioctl seems easier than names. Userspace might be less > likely to hardcode random id numbers vs. names as well. In the futur I think that heap type will be replaced by a "get caps" ioctl which will describe heap capabilities. At least that is my understanding of kernel part of "unix memory allocator" project > > Thanks, > Laura -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: benjamin.gaignard@linaro.org (Benjamin Gaignard) Date: Tue, 14 Mar 2017 15:47:54 +0100 Subject: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging In-Reply-To: <6d3d52ba-29a9-701f-2948-00ce28282975@redhat.com> References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <20170303132949.GC31582@dhcp22.suse.cz> <20170306074258.GA27953@dhcp22.suse.cz> <20170306104041.zghsicrnadoap7lp@phenom.ffwll.local> <20170306105805.jsq44kfxhsvazkm6@sirena.org.uk> <20170306160437.sf7bksorlnw7u372@phenom.ffwll.local> <26bc57ae-d88f-4ea0-d666-2c1a02bf866f@redhat.com> <6d3d52ba-29a9-701f-2948-00ce28282975@redhat.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 2017-03-13 22:09 GMT+01:00 Laura Abbott : > On 03/12/2017 12:05 PM, Daniel Vetter wrote: >> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard >> wrote: >>> 2017-03-09 18:38 GMT+01:00 Laura Abbott : >>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter : >>>>>> 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.... >> >> I think ion should expose any heap that's also directly accessible to >> devices using dma_alloc(_coherent). That should leave very few things >> left, like your SMA heap. >> >>> 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. >> >> Hm, we might want to expose all the heaps as individual >> /dev/ion_$heapname nodes? Should we do this from the start, since >> we're massively revamping the uapi anyway (imo not needed, current >> state seems to work too)? >> -Daniel >> > > I thought about that. One advantage with separate /dev/ion_$heap Should we use /devi/ion/$heap instead of /dev/ion_$heap ? I think it would be easier for user to look into one directory rather then in whole /dev to find the heaps > is that we don't have to worry about a limit of 32 possible > heaps per system (32-bit heap id allocation field). But dealing > with an ioctl seems easier than names. Userspace might be less > likely to hardcode random id numbers vs. names as well. In the futur I think that heap type will be replaced by a "get caps" ioctl which will describe heap capabilities. At least that is my understanding of kernel part of "unix memory allocator" project > > Thanks, > Laura From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Gaignard Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Date: Tue, 14 Mar 2017 15:47:54 +0100 Message-ID: References: <1488491084-17252-1-git-send-email-labbott@redhat.com> <20170303132949.GC31582@dhcp22.suse.cz> <20170306074258.GA27953@dhcp22.suse.cz> <20170306104041.zghsicrnadoap7lp@phenom.ffwll.local> <20170306105805.jsq44kfxhsvazkm6@sirena.org.uk> <20170306160437.sf7bksorlnw7u372@phenom.ffwll.local> <26bc57ae-d88f-4ea0-d666-2c1a02bf866f@redhat.com> <6d3d52ba-29a9-701f-2948-00ce28282975@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6d3d52ba-29a9-701f-2948-00ce28282975@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Laura Abbott Cc: devel@driverdev.osuosl.org, Rom Lemarchand , Brian Starkey , Daniel Vetter , Riley Andrews , "dri-devel@lists.freedesktop.org" , Michal Hocko , "linaro-mm-sig@lists.linaro.org" , Linux MM , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Mark Brown , "linux-arm-kernel@lists.infradead.org" , Greg Kroah-Hartman , Daniel Vetter , Sumit Semwal , Linux Kernel Mailing List , "linux-media@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org 2017-03-13 22:09 GMT+01:00 Laura Abbott : > On 03/12/2017 12:05 PM, Daniel Vetter wrote: >> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard >> wrote: >>> 2017-03-09 18:38 GMT+01:00 Laura Abbott : >>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter : >>>>>> 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.... >> >> I think ion should expose any heap that's also directly accessible to >> devices using dma_alloc(_coherent). That should leave very few things >> left, like your SMA heap. >> >>> 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. >> >> Hm, we might want to expose all the heaps as individual >> /dev/ion_$heapname nodes? Should we do this from the start, since >> we're massively revamping the uapi anyway (imo not needed, current >> state seems to work too)? >> -Daniel >> > > I thought about that. One advantage with separate /dev/ion_$heap Should we use /devi/ion/$heap instead of /dev/ion_$heap ? I think it would be easier for user to look into one directory rather then in whole /dev to find the heaps > is that we don't have to worry about a limit of 32 possible > heaps per system (32-bit heap id allocation field). But dealing > with an ioctl seems easier than names. Userspace might be less > likely to hardcode random id numbers vs. names as well. In the futur I think that heap type will be replaced by a "get caps" ioctl which will describe heap capabilities. At least that is my understanding of kernel part of "unix memory allocator" project > > Thanks, > Laura