Date: Tue, 21 Jan 2003 19:04:29 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> Cc: Robert Watson <rwatson@FreeBSD.ORG>, phk@FreeBSD.ORG, "Alan L. Cox" <alc@imimic.com>, arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301220304.h0M34TMB099694@apollo.backplane.com> References: <20030121185208.A82EB2A7EA@canning.wemm.org>
index | next in thread | previous in thread | raw e-mail
:> (1) shmfs.
:>
:> mount -t shmfs foo /shmfs
:>
:> Handle the implementation using vnodes and DTYPE_VNODE
:
:> (2) /dev/shm
:>
:> Handle the implementation using cloning devices and device pager
:> magic.
:>
:> (3) DTYPE_MEMFD
:>
:> Handle the implementation using a special file descriptor type
:> creating using a special creation primitive (similar to kqueue,
:> pipe, etc).
:>
:> Of the three, (3) appears to be simplist to implement, (1) the most
:> complicated. I'm probably not qualified to comment on (2), but have to
:> say that (3) would be the easiest to stick in MAC magic for :-). But only
:> if (3) completely avoids the kitchensinkfd() approach. From the API
:> perspective, you could easily hide any of these behind a memfd() library
:> call.
:
:(2) and (3) are not all that different, except that (2) requires another
:hack in the mmap syscall code to recognize and magically convert.
:(3) is cleaner but requires a more code to add the DTYPE_xxxFD stuff and
:affects more places in the kernel where we switch() on fd types. I
:personally prefer (3) - which is what Matt has implemented, but could
:live with (2). (1) is way more complicated than I want to think about
:especially if it goes near vnodes.
:
:What I'm objecting to though is the syscall that is wrapped around (3) in
:Matt's patch. I'd rather use a seperate syscall for any new uses of the
:system (timers, whatever) rather than try and come up with a future proof
:uber-syscall. What if down the track we discover that we could do
:something nifty and reuse part of this, but we need two configuration args
:to the syscall.. What then? getsysfd2(....)? I'd rather that we just
:create the syscalls for the specific purpose that they're needed for.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
I don't mind implementing (3) and making it MEMFD specific (not
trying to make the syscall capable of more general purpose ops).
I will note that (1) would be a step backwards rather then forwards,
mainly because we already have a great security paradigm with the
normal filesystem and the normal filesystem already spans user-writable
filespace (their home directory). All it would take to support a
memory-specific namespace rendezvous would be one additional field
in the vnode structure (which IMHO is how FIFOs should have been
implemented). So, for example:
fd = getmemfd(const char *path, off_t size)
fd = getmemfd(NULL, size);
fd = getmemfd("/var/db/blah.rendezvous", size);
xfd = open("/var/db/blah.rendezvous", O_CREAT|O_TRUNC, 0666);
fd = fgetmemfd(xfd, size);
The memory descriptor 'fd' would not in any way be associated with the
file's data space (i.e. the file's size is irrelevant), the file would
simply act as a rendezvous.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301220304.h0M34TMB099694>