On 29/04/16 11:39, Chris Wilson wrote:
On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote:
On 29/04/16 11:18, Chris Wilson wrote:
On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote:
I don't get it - if we are adding something why not add it in a way
that makes it clear and self-contained - what is the downside of
what I propose to meet such resistance?
You're suggesting to add a field I'm not going to use. Is any one?
Until there is an actual use (which would afaict be if one of the
existing values changed meaning, which itself would be an abi break) I'm
not convinced we should be designing for the unknowable. If we did need
to version would we not be better off with a new ioctl?
I am suggesting if we are adding aper_total_size, or whatever it is
called, to make it usable in an self-contained matter.
My impression was you want aper_total_size so I was simply objecting
to adding it without being able to directly tell if kernel actually
supports that extension.
The two additions that I thought we have reduced it to:
u64 mappable_aperture_size
u64 stolen_size;
Of which I agree that the first has some ambiguity over 0. But I don't
think it makes a difference in practice. I for one would not bother with
checking a version. I already have a cascade here to deal with not being
able to use various probes, with an eventual fallback to a safe value.
We know the mappable_aperture_size cannot be zero with the exception
that the device is disabled - but we have opened the device already.
Since you agree there is ambiguity lets just add a version. You don't
have to use it, but someone will.
u32 version; // == 1
u64 mappable_aperture_size;
And then it is clear and self-contained.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
