Re: [PATCH 2/3] drm/panfrost: Expose HW counters to userspace

From: Eric Anholt <eric@anholt.net>
To: Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Boris Brezillon <boris.brezillon@collabora.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	kernel@collabora.com, dri-devel@lists.freedesktop.org,
	Neil Armstrong <narmstrong@baylibre.com>
Subject: Re: [PATCH 2/3] drm/panfrost: Expose HW counters to userspace
Date: Fri, 05 Apr 2019 08:36:32 -0700	[thread overview]
Message-ID: <87wok8tqf3.fsf@anholt.net> (raw)
In-Reply-To: <20190404154129.GA2999@rosenzweig.io>

[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]

Alyssa Rosenzweig <alyssa@rosenzweig.io> writes:
>> @@ -55,6 +63,15 @@ struct drm_panfrost_submit {
>>  
>>  	/** A combination of PANFROST_JD_REQ_* */
>>  	__u32 requirements;
>> +
>> +	/** Pointer to a u32 array of perfmons that should be attached to the job. */
>> +	__u64 perfmon_handles;
>> +
>> +	/** Number of perfmon handles passed in (size is that times 4). */
>> +	__u32 perfmon_handle_count;
>> +
>> +	/** Unused field, should be set to 0. */
>> +	__u32 padding;
>
> Bleep blorp. If we're modifying _submit, we'll need to be swift about
> merging this ahead of the main code to make sure we don't break the
> UABI. Although I guess if we're just adding fields at the end, that's a
> nonissue.

You can extend ioctl structs safely.  When older userspace passes theirs
in, it has the shorter length encoded in the cmd. The kernel allocates
the newest version's space, copies in the shorter struct, and
zero-extends the rest.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel