From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?windows-1252?Q?Christian_K=F6nig?= Subject: Re: AMD GPU new API for new module Date: Thu, 09 Oct 2014 11:49:15 +0200 Message-ID: <54365A1B.8070409@vodafone.de> References: <20141008160026.GA7643@gmail.com> <20141009075440.GA4576@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from pegasos-out.vodafone.de (pegasos-out.vodafone.de [80.84.1.38]) by gabe.freedesktop.org (Postfix) with ESMTP id EC5F56E332 for ; Thu, 9 Oct 2014 02:49:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by pegasos-out.vodafone.de (Rohrpostix2 Daemon) with ESMTP id 571655EC2F9 for ; Thu, 9 Oct 2014 11:49:50 +0200 (CEST) Received: from pegasos-out.vodafone.de ([127.0.0.1]) by localhost (rohrpostix2.prod.vfnet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3nUFBeojgNq for ; Thu, 9 Oct 2014 11:49:28 +0200 (CEST) In-Reply-To: <20141009075440.GA4576@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jerome Glisse , Rob Clark Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org Am 09.10.2014 um 09:54 schrieb Jerome Glisse: > On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote: >> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrot= e: >>> So idea is simple, each ioctl would use some struct like : >>> >>> struct radeon_ioctl { >>> u32 version; >>> u32 size; >>> }; >> >> fwiw, drm_ioctl() will do the right thing (zero-pad) for growing >> ioctls these days.. > It's more about userspace knowing about ioctl XY and having a way > to override/ask for special version of each ioctl. So if we screw > ioctl XY, we can add a new version to XY and we can try to work > around if userspace still request the old version. It is mostly > about trying to keep the code clean and avoiding things like the > chunk stuff of the cs ioctl. > > For instance if you cs ioctl with the following struct as ioctl > parameter: > > struct drm_radeon_cs_ioctl_version_00 { > u64 *cs; > u32 size; > u32 flags; > }; > > And now you have a new generation of hardware or are just adding > a new feature : > > struct drm_radeon_cs_ioctl_version_01 { > u64 *cs; > u32 size; > u32 flags; > u32 newfeature fields; > }; > > Of course you can argue that you could use the size of user space > paremeter to do this simple example. But with versioning you can > also move fields around, remove fields, ... basicly it is just more > flexible with small overhead of having one more indirection but this > will be lost into the ioctl cost anyway (i highly doubt it would > turns as a bottleneck). I think we can live perfectly fine with adding new fields to the end of = the IOCTL interface structure and if we really find a need to completely = redesign an IOCTL just use a new IOCTL number. IIRC they are 32bit at = least so running out of IOCTL numbers is rather unlikely. Regards, Christian. > > Cheers, > J=E9r=F4me > >> BR, >> -R > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel