Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965512AbdIYS0b (ORCPT ); Mon, 25 Sep 2017 14:26:31 -0400 Received: from mail-pg0-f42.google.com ([74.125.83.42]:44165 "EHLO mail-pg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964892AbdIYS0a (ORCPT ); Mon, 25 Sep 2017 14:26:30 -0400 X-Google-Smtp-Source: AOwi7QBU6Mi7xyOPaPY9Crpwk8vETXTce315ETOoy3pN3W9qFuC13asR+7c8xKjEx9norv+A3T4Fgg== Subject: Re: [PATCH v3 2/2] staging: ion: create one device entry per heap To: Benjamin Gaignard , sumit.semwal@linaro.org, gregkh@linuxfoundation.org, arve@android.com, riandrews@android.com, broonie@kernel.org, dan.carpenter@oracle.com Cc: devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org References: <1505897105-23721-1-git-send-email-benjamin.gaignard@linaro.org> <1505897105-23721-3-git-send-email-benjamin.gaignard@linaro.org> From: Laura Abbott Message-ID: <3dbd167f-c381-8451-5861-3788634885b7@redhat.com> Date: Mon, 25 Sep 2017 11:26:27 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1505897105-23721-3-git-send-email-benjamin.gaignard@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1134 Lines: 29 On 09/20/2017 01:45 AM, Benjamin Gaignard wrote: > Instead a getting one common device "/dev/ion" for > all the heaps this patch allow to create one device > entry ("/dev/ionX") per heap. > Getting an entry per heap could allow to set security rules > per heap and global ones for all heaps. > > Allocation requests will be only allowed if the mask_id > match with device minor. > Query request could be done on any of the devices. > Deivce node major will also change and that may impact init scripts. > We should start Cc linux-api for future changes since we're going to have more than just /dev/ion. Thinking about this some more, I think we need to allow backwards compatibility. It's just not feasible to keep throwing workarounds into userspace if we can avoid it. I'd propose keeping the old /dev/ion misc interface available under a Kconfig and then creating the new split heaps in parallel. On a somewhat related note, there was some interest in possibly having a sysfs interface for Ion long term. I don't think this needs to happen right now but I'd like whatever we do to not make adding that harder. Thanks, Laura