Date: Sat, 11 Jan 2003 15:42:45 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> Cc: "Alan L. Cox" <alc@imimic.com>, arch@FreeBSD.ORG Subject: Re: Virtual memory question Message-ID: <200301112342.h0BNgj9a048596@apollo.backplane.com> References: <20030111224444.94D102A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Speaking of which, I've been thinking about some sort of non-fs persistent
:object handle for doing mmaps. (Note: thinking about, not actually getting
:around to doing :-).
:
:Imagine mmapping /dev/zero, but having a persistent object per fd that was
:opened. This would be to enable things like fd passing to get access to
:another process's store and so on. Basically a replacement for the
:MAP_NOSYNC files, and it would be swap backed instead of vfs backed.
:
:This would be very damn useful at work. It could be ideal for malloc too
:since it would be a single object with coherent ordering etc. At work, we
:have lots of problems with complications of having a file system attached
:to things that we just want to shove data into and otherwise forget about.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
This is basically how shared memory works, except that shared memory
is managed outside the file descriptor framework. I would love to
see a shared memory object that is managed inside the file
descriptor framework, sort of like 'pipe()'. I do not see any need
to use /dev/zero to implement the feature, though, because it will
not improve portability.
How about something like:
getmemfd().
You would then be able to mmap() to your heart's content. We
wouldn't even need to implement ftruncate(), we could just
default it to a 64 bit object space.
fd = getmemfd();
mmap(...)
pass the descriptor around, etc.
BTW, this would be utterly trivial to implement. I don't even
think we need a VFS. Just a fileops set.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301112342.h0BNgj9a048596>