> Date: Fri, 15 Nov 2013 02:16:19 -0500 (EST) > From: Mouse <[email protected]> > > > My understanding is that the new code, by passing shared memory > > through fd is a lot better since [...] > > In those respects, yes. But it's worse in that it requires write > access to a filesystem - a filesystem which supports mmap - with space > enough to hold the shared memory segments, which MIT-SHM doesn't.
That's not really true. POSIX defines interfaces to create and remove shared memory objects: shm_open() and shm_unlink(). On most systems these interfaces are just thin wrappers around open() and unlink() that create files in a suitable location. But a kernel implemantation that isn't tied to a real filesystem is also possible. And even the wrapper approach at least abstracts away the knowledge about where to put the files; a good implementation would probably use a dedicated in-memory filesystem for this. Keith mentioned the other day that he didn't use shm_open() because of security concerns. However shm_open()/shm_unlink() isn't inherently less secure than using open()/unlink(). It's just that it is rather easy to use shm_open() in a unsecure way. The same risk exists if you would use open() directly, but in that case there is mkstemp() to prevent you from shooting yourself in the foot. That's why OpenBSD has shm_mkstemp(). It does look like NetBSD doesn't have shm_open() and shm_unlink() yet though. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
