Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752960AbdCNU2I (ORCPT ); Tue, 14 Mar 2017 16:28:08 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:36733 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752553AbdCNU2G (ORCPT ); Tue, 14 Mar 2017 16:28:06 -0400 Message-ID: <1489523282.28116.10.camel@ndufresne.ca> Subject: Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging From: Nicolas Dufresne To: Benjamin Gaignard , Laura Abbott Cc: Daniel Vetter , Mark Brown , Michal Hocko , Sumit Semwal , Riley Andrews , Arve =?ISO-8859-1?Q?Hj=F8nnev=E5g?= , 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 Date: Tue, 14 Mar 2017 16:28:02 -0400 In-Reply-To: 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> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-4yF7GXm+/h6FVvfyggOu" X-Mailer: Evolution 3.22.4 (3.22.4-2.fc25) Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1416 Lines: 41 --=-4yF7GXm+/h6FVvfyggOu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mardi 14 mars 2017 =C3=A0 15:47 +0100, Benjamin Gaignard a =C3=A9crit=C2= =A0: > 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 >=20 > > 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. >=20 > 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 I think what we really need from userspace point of view, is the ability to find a compatible heap for a set of drivers. And this without specific knowledge of the drivers. Nicolas --=-4yF7GXm+/h6FVvfyggOu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAljIUlIACgkQcVMCLawGqBw6ogCgysy19SbY1BaDre6iIXHMkz5R SPkAoJIx3dzdLVwHCLbVpFbqLZQL+M+K =tmAm -----END PGP SIGNATURE----- --=-4yF7GXm+/h6FVvfyggOu--