>>> 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. [...shm_open() and shm_unlink()...]
This makes sense to me only if you're saying that this newer interface uses them and thus doesn't necessarily use filesystem permissions. But you say it doesn't use them, and if it did it would be breaking support for everything not quite bleeding-edge enough to have shm_open, which would be its own value of "worse in that...". (It also just changes what I wrote to "...usually requires write access to..., but maybe uses something else even less understood by admins", which has its own issues.) > And even the wrapper approach at least abstracts away the knowledge > about where to put the files; I'm not convinced that's a good thing, because it also removes control over where to put the files (when there are files). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ 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