[Intel-gfx] [PATCH 11/11] drm/i915: Extend GET_APERTURE ioctl to report available map space
Emil Velikov
emil.l.velikov at gmail.com
Wed Jun 1 12:31:26 UTC 2016
On 1 June 2016 at 13:11, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> [+Daniel Vetter]
>
> Hi Ankitprasad,
>
> On 31 May 2016 at 07:19, <ankitprasad.r.sharma at intel.com> wrote:
>
>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
> Seems like you've picked the patch from the mailing list, which does
> s/@/ at /. You might want to revert that and normalise the emails.
>
>> --- a/include/uapi/drm/i915_drm.h
>> +++ b/include/uapi/drm/i915_drm.h
>> @@ -1011,6 +1011,23 @@ struct drm_i915_gem_get_aperture {
>> * bytes
>> */
>> __u64 aper_available_size;
>> +
>> + /**
>> + * Versioning to indicate if map_total_size and stolen_total_size
>> + * value returned are valid or not
>> + */
>> + __u64 version;
>> +
>> + /**
>> + * Total space in the mappable region of the aperture, in bytes
>> + */
>> + __u64 map_total_size;
>> +
>> + /**
>> + * Total space in the stolen region, in bytes
>> + */
>> + __u64 stolen_total_size;
>> +
> I'm not sure if this is going to work with old userspace/new kernel
> and vice-versa. Are you sure that things won't explode in such cases ?
> Sadly this struct is missing flag field, so I'm not sure how one can
> extend it without breaking things - Daniel, any ideas ?
>
Please ignore this. Daniel just pointed out that this cannot happen as
drm_ioctl() handles any issues this could have caused.
Thanks
Emil
More information about the Intel-gfx
mailing list