> From: Keith Packard <[email protected]> > Date: Tue, 19 Nov 2013 22:35:13 -0800 > > Keith Packard <[email protected]> writes: > > > The new MIT-SHM CreateSegment request needs to stick the requested > > shared memory file someplace in the file system. Precisely where it > > needs to live depends on the target system. > > > > [PATCH 1/2] Select directory for MIT-SHM temp files at configure time > > > The first of these patches allows that to be configured in the X > > server build process. By default, it looks through a list of likely > > spots, picking the first that it finds. Of course, you can also > > specify the directory on the configure command line using > > --with-shared-memory-dir=3DPATH > > I haven't seen anyone from non-Debian land chime in about this patch -- > it's designed to auto-detect a suitable directory for SHM temp files > that the X server creates. I'd love a 'Reviewed-by:', or even a > 'Tested-by:' as I want to merge this fix in time for another RC this > Friday.
I still think the X server should not be concerned with picking a suitable directory, but instead should use shm_open/shm_unlink... > > [PATCH 2/2] Xext: Use SHMDIR and O_TMPFILE when creating mapping > > > > The second patch actually uses that directory in the MIT-SHM > > extension, at the same time it also adds support for the new Linux > > O_TMPFILE flag, which avoids ever needing a name for the file nicely. > > > > To test the patch, I needed to stick this in the file above the call > > as my glibc doesn't yet have the necessary O_TMPFILE define. > > > > /* Hacks needed until glibc has O_TMPFILE */ > > #define __O_TMPFILE 020000000 > > #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY) > > I'd also like to hear from anyone who can test this patch; it's a useful > change in that it avoids all of the pitfalls of mkstemp as used by the > existing code. Something even as simple as 'this should wait until after > 1.15 as it's not a serious bug fix' would be great. ...but some thought is required on how to use O_TMPFILE with shm_open. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
