xserver with DRI3 shm.c: unknown type name: xShmAttachFdReq and xShmCreateSegmentReq

[Mark Kettenis]

> From: Keith Packard <keithp at keithp.com>
> Date: Mon, 04 Nov 2013 08:56:50 -0800
> 
> Alan Coopersmith <alan.coopersmith at oracle.com> writes:
> 
> > On 11/ 2/13 04:55 PM, Gaetan Nadon wrote:
> >> I can't find where those types are defined. Should they be in shmproto.h?
> >
> > In http://patchwork.freedesktop.org/patch/15082/ which Keith's xserver changes
> > require, but he hasn't pushed to the xextproto git repo yet.
> 
> I've pushed them this morning; would love to get additional comments on
> whether people think the new requests need some kind of signal that
> they're avaialble. I know it's easy to say 'yes, of course, just in
> case', but does anyone know of a system which supports SysV shared
> memory and which does *not* support file descriptor passing of mmap'able
> files?

Cygwin might fall into that category.  Everything that's derived from
4.3 BSD has file descriptor passing although supporting the original
4.3 BSD way would need substantial modifications to your libxtrans
code which (mostly) implements the 4.4 BSD API.  This obviously
includes all the BSDs and Mac OS X.  Older System V derivatives might
not support file descriptor passing, but Solaris, AIX, HP-UX and IRIX
do support it.  Of those systems only HP-UX and IRIX seem to implement
the old 4.3 BSD interface, and I doubt we still care about those
systems.

> Not requiring applications do multiple levels of checks for
> features seems like it will simplify application adoption of this new
> mechanism as applications could support *only* the new requests instead
> of having to support both.

I suppose that if there will ever be a version 1.4 of the protocol and
the desire exists to support that on systems that don't want to or
can't offer file descriptor passing we could always add the flag in
1.4.  Meanwhile implementations that don't offer this feature can
simply continue to advertise 1.2.