[PATCH:shmfd 2/2] Use /var/tmp instead of /run/shm on non-linux OS'es

[Mark Kettenis]

> From: Keith Packard <keithp at keithp.com>
> Date: Mon, 11 Nov 2013 11:04:58 -0800
> 
> Alan Coopersmith <alan.coopersmith at oracle.com> writes:
> 
> > Possibly - I didn't know why Keith chose /run/shm in the first place.
> 
> /run/shm was suggested by "someone" as a suitable new standard place to
> use instead, and it happened to work in Debian...
> 
> I think the right plan will be to have configure.ac walk a list of
> potential directories and pick one, with the ability to override that
> choice on the configure command line. I'll see if I can't cook up a
> suitable patch today.
> 
> Note that *nothing* depends on the actual path; we just need some file
> system to create this file in.

The right thing is almost certainly to use shm_open(3) to create
proper shared memory objects.  Which on most platforms is just a thin
wrapper around open(2) that knows the best place in the filesystem
hierarchy to create the file.  There are some issues with that though:

1. shm_open(3) is hard to use safely; it pretty much forces you to use
   mktemp(3) with all its traps.  This is why some people suggested we
   need shm_mkstemp(3), and Ted Unangst actually implemented this on
   OpenBSD.  The code under the ISC license, so it shouldn't be an
   issue to include it in Xorg.

2. shm_open(3) (and shm_mkstemp(3)) will set the FD_CLOEXEC flag on
   the file descriptor.  This is actually a good thing, but it means
   you'll have to unset that flag if you want to share the
   filedescriptor by doing a fork(2) and exec(2).

3. Some systems don't have shm_open(3).  But I guess pretty much all
   systems that support file descriptor passing using the 4.4BSD
   interface do support it.  And it's always possible to fall back to
   code that's more or less equivalent to what we have now.

I'll see if I can whip up a diff that does this, but it'll probably
take a couple of days.