Date: Mon, 11 May 2009 12:35:40 -0400 From: Garrett Wollman <wollman@bimajority.org> To: Lothar Scholz <scholz@scriptolutions.com> Cc: arch@freebsd.org Subject: Re: Posix shared memory problem Message-ID: <18952.21468.748665.878710@hergotha.csail.mit.edu> In-Reply-To: <1393224851.20090511112537@scriptolutions.com> References: <mit.lcs.mail.freebsd-arch/588815840.20090509203115@scriptolutions.com> <mit.lcs.mail.freebsd-arch/20090509200724.GA25714@stack.nl> <200905100500.n4A50GOa050728@hergotha.csail.mit.edu> <7710650619.20090510075706@scriptolutions.com> <18950.63671.323324.756287@hergotha.csail.mit.edu> <1393224851.20090511112537@scriptolutions.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Mon, 11 May 2009 11:25:37 +0200, Lothar Scholz <scholz@scriptolutions.com> said: > Some idiots started to think about this as a file path. But it isn't > and it shouldn't. Actually, it really should be. Ask a security person or a virtualization person to explain why an unnecessary multiplicity of namespaces is a bad idea. > If i have to find a useable filefile location anyway the whole > function does not make any sense, then i can directly use mmap. But of course you won't get the same behavior, because open()/mmap() guarantees that the backing store will get updated. That's why there's a separate interface. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18952.21468.748665.878710>