[PATCH libdrm] add libsync.h helper

[Rob Clark]

On Mon, Oct 31, 2016 at 1:15 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 31 October 2016 at 16:39, Rob Clark <robdclark at gmail.com> wrote:
>> On Mon, Oct 31, 2016 at 11:25 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> On 31 October 2016 at 13:44, Rob Clark <robdclark at gmail.com> wrote:
>>>> From: Rob Clark <robclark at freedesktop.org>
>>>>
>>>> Rather than cut/pasting these couple ioctl wrappers everywhere, just
>>>> stuff them as static-inline into a header.
>>>>
>>>> Signed-off-by: Rob Clark <robclark at freedesktop.org>
>>>> ---
>>>> This is probably mostly used from mesa, but some drivers, test apps, etc
>>>> may also want to use it from libdrm.
>>>>
>>> It makes sense imho. To avoid fun experiences we want the header
>>> synced in an identical manner (make headers_install) to the
>>> include/drm ones. One might as well move it there, so make its "more"
>>> obvious.
>>>
>>
>> hmm, not sure I understand, but '#include <libsync.h>' seems to work
>> in either case..
>>
> The file is from the kernel UAPI, correct ? If so store it alongside
> the other UAPI ones include/drm/ and import `make headers_install'
> (see git log -- include/drm for examples).

no, it copy/pastes a few lines from uabi/linux/sync_file.h just to
avoid a dependency on kernel headers.  I guess I *could* copy
sync_file.h into libdrm, but it isn't really a drm uabi header, so I
didn't want to do that

BR,
-R

> We should add a README with the above specifics to include/drm/ one of
> these days :-)
>
>>>
>>>> +static inline int sync_wait(int fd, int timeout)
>>>> +{
>>>> +       struct pollfd fds;
>>>> +
>>>> +       fds.fd = fd;
>>>> +       fds.events = POLLIN | POLLERR;
>>> IIRC the API does not mention (forbid even) additional members of the
>>> pollfd struct.
>>> Let's zero init fds, and the compiler will drop it if/where applicable ?
>>
>>
>> hmm, and I guess if this gets #include'd from c++ code, does it get
>> more fun?  I thought there were some different rules about struct
>> initializers in c++?  Or maybe that was just with certain compilers?
>>
> Initializers are fun in C++ indeed. Having the extern C wrappers (as
> per your v2) helps.
>
> Thanks
> Emil