Date: Tue, 21 Jan 2003 20:15:46 -0800 From: Peter Wemm <peter@wemm.org> To: Matthew Dillon <dillon@apollo.backplane.com> 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: <20030122041546.393AF2A8A5@canning.wemm.org> In-Reply-To: <200301220304.h0M34TMB099694@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> :> (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.
I always kinda liked the SVR4 fattach(2) and fdetach(2) syscalls. You
could do arbitary things like this:
pipe(fds);
fattach("/var/inpipe", pfd[0]);
and so on. I think this was how fifos were actually implemented. The
rendesvous point counted as an "open" reference count. If all the processes
closed it, the file entity wouldn't go away till the node was rm'ed.
fdetach(2) also did the obvious thing.
I'd rather do that than add another arg to the memfd syscall. Otherwise
we're heading into shm_open() look and feel territory. Hmm. I wonder if
the POSIX folks would object to us calling the syscall shm_openfd() ?
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?20030122041546.393AF2A8A5>