> From: Keith Packard <kei...@keithp.com> > Date: Mon, 11 Nov 2013 11:04:58 -0800 > > Alan Coopersmith <alan.coopersm...@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. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel