Re: AMD GPU new API for new module

["Christian König" <deathsimple@vodafone.de>]

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 <j.glisse@gmail.com> wrote:
>>> 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érôme
>
>> BR,
>> -R
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel