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 at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
