Received: by 10.223.164.221 with SMTP id h29csp2981553wrb; Tue, 3 Oct 2017 14:43:12 -0700 (PDT) X-Received: by 10.84.215.22 with SMTP id k22mr17919216pli.284.1507066992024; Tue, 03 Oct 2017 14:43:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507066991; cv=none; d=google.com; s=arc-20160816; b=cfDZwp4qpn0kKFJK3DAw9V2LWBTICadE/OdkbstTYB1fjzd9aHZq866UuXwE0zlpfv riBfPMjfPXKfL7MWLgg9Ja1B8wKPsim2okVx1bNemA63FplExmylWKbzbcPnYGvIvqRS 1I1OufxGTOi4bbeerZToaxq5aMvPOBN92UqnFS43mx28DL0snM7TSAE0eeE0OIN7+MAh JRzYLD7mcipcKW5CbCd0EQVcTdgqVyqEg3UP+EThIq8CwFvpwiB9M3cV+BdHqMSA6AAk c7IT1ZmU869n6yvijqVCqVrnyDiD9Jq8ll41v0rsUCMVB16UFaUhpE368hqiwI6gM9/b Rl+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=/N2Ju3+G56LpCsIiWbKAVgnnbKOE5eBhBHWZgp82wRM=; b=O8hir9HoRk1xT1Ye5U/pf45cXho5Ms5mySrhGhmhekUhDHLXxcLthcOaEWxw0w8I9N FquRQUyAIpo161hGv8Iz4V+Zec2YSZH14k/1IFpXRCm9OhZKuGS1mTNZRHJUhUK/bm37 J+jZYtOAxTzGOv+9x0KoR4+GGdAwSj6V82eSdt0JfAAXfALYnW6d+BwpFHsW1tp2oBmj XJe/GWg9mNZUr9eUlsW4ytBnuiTE4HRiWzQ9YjUY848mKWTPcYOKGjmh10dBGH9sfG7e pMnLFKC9pfVa9hJNe5Tz3DQR62/nFU/3/bQ6xQ0DKzKncjsYjoHVPMFdgfEJjiJSqXfb rIbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h8si10009358pgq.63.2017.10.03.14.42.57; Tue, 03 Oct 2017 14:43:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751420AbdJCVmh (ORCPT + 99 others); Tue, 3 Oct 2017 17:42:37 -0400 Received: from mail-qk0-f182.google.com ([209.85.220.182]:55544 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750841AbdJCVmg (ORCPT ); Tue, 3 Oct 2017 17:42:36 -0400 Received: by mail-qk0-f182.google.com with SMTP id q8so9676707qkl.12 for ; Tue, 03 Oct 2017 14:42:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/N2Ju3+G56LpCsIiWbKAVgnnbKOE5eBhBHWZgp82wRM=; b=UGrbefkFJxTyph6qS1AYcaeIzpf42LPRiVBtt/2aWekNNkiKAg44uwBYv91KYzHb+V pJZTpD8Z8rn0izqjYxei2tAGA74FytgKSHYEDndwbyEHwicxfvKaQngG6t76HkXCbiTY fqnTQbkVum8PRJVrdgAdkeEhvYVrxL/UHZRsSoFMl4Bx29pfIn1OzF4fuLgMTU3RIjUU cS4QwIPVTIWkVrE60UOkZxxjF8TqnJUuG6rVIVQ2UhEGFDAGOIsc34bQVPoVfUQYvNL2 D4z6UHgrNQhTG2A8a7CWQjR2tyfG2VytKCBjRVXp4PjhANvkDkuOgfJM3otVTXZUvLwU i4GA== X-Gm-Message-State: AMCzsaUNsdkSddN7nvchv86iI9doniTk4YNUlTtwGKJ6f8ukarfPyNoY xCDDAvQ+BzPgYJYyWwWmtjTJhA== X-Google-Smtp-Source: AOwi7QAGh4S9dxDJk77ni0F5yYazlKIe1ozu7uENq51SAi6kGXL2nhqqLKLsBkpNjwJYCwU8c2HaEg== X-Received: by 10.233.237.193 with SMTP id c184mr11413851qkg.265.1507066955804; Tue, 03 Oct 2017 14:42:35 -0700 (PDT) Received: from ?IPv6:2601:602:9802:a8dc::e174? ([2601:602:9802:a8dc::e174]) by smtp.gmail.com with ESMTPSA id 6sm8902906qkh.8.2017.10.03.14.42.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 14:42:34 -0700 (PDT) Subject: Re: [PATCH v5 2/2] staging: ion: create one device entry per heap To: Mark Brown Cc: Benjamin Gaignard , sumit.semwal@linaro.org, gregkh@linuxfoundation.org, arve@android.com, riandrews@android.com, dan.carpenter@oracle.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-api@vger.kernel.org References: <1506518409-16887-1-git-send-email-benjamin.gaignard@linaro.org> <1506518409-16887-3-git-send-email-benjamin.gaignard@linaro.org> <2e15edc2-a17f-3930-7d5b-4b5b7d2e0a4d@redhat.com> <20171003164849.rcdgez6lbpmq5llt@sirena.org.uk> From: Laura Abbott Message-ID: <2417c969-357f-d5d9-153a-2180d09b0dc6@redhat.com> Date: Tue, 3 Oct 2017 14:42:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171003164849.rcdgez6lbpmq5llt@sirena.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/03/2017 09:48 AM, Mark Brown wrote: > On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote: > >> Thinking about this a bit more, I'm not 100% sure if this >> will allow the security rules we want. Heap ids are assigned >> dynamically and therefore so will the /dev/ionX designation. >> From my understanding, security rules like selinux need to >> be fully specified at boot time so I'm not sure how you would >> be able to write rules to differentiate between /dev/ionX and >> /dev/ionY without knowing the values at boottime. > > Isn't this something that should be managable via udev rules that ensure > stable names in the same way as for things like disks or ethernet > controllers (even if it just ends up doing something like /dev/ion-gpu > or whatever)? If we're not giving it enough information to assign stable > names where needed we probably need to fix that anyway. > Android doesn't use a standard udev so we'd need something that would work there. My understanding was that android needs everything specified at boot unless that's changed. There would be enough information to assign stable names (e.g. /dev/ion-system) if we used the query ioctl to find out what's actually available. Is just the ioctl useful though? Thanks, Laura From 1580255843453751902@xxx Tue Oct 03 16:50:11 +0000 2017 X-GM-THRID: 1579699119100728687 X-Gmail-Labels: Inbox,Category Forums