Date: Tue, 21 Jan 2003 10:52:08 -0800 From: Peter Wemm <peter@wemm.org> To: Robert Watson <rwatson@freebsd.org> Cc: phk@freebsd.org, Matthew Dillon <dillon@apollo.backplane.com>, "Alan L. Cox" <alc@imimic.com>, arch@freebsd.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <20030121185208.A82EB2A7EA@canning.wemm.org> In-Reply-To: <Pine.NEB.3.96L.1030121132828.11405D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
>
> On Tue, 21 Jan 2003 phk@freebsd.org wrote:
>
> > In message <Pine.NEB.3.96L.1030121125651.11405B-100000@fledge.watson.org>,
Robe
> > rt Watson writes:
> > >
> > >Ok, so lemme revise my thinking. Could we take this patch, rename the API
> > >from getsysfd(various things) to memfd(size), and simply provide anonymous
> > >swap-backed memory only?
> >
> > The traditional design would be:
> >
> > fd = open("/dev/shmem", ...);
> > ptr = mmap(..., fd, ...)
>
> Well, it struck me the three implementations that came to mind would be:
>
> (1) shmfs.
>
> mount -t shmfs foo /shmfs
>
> Handle the implementation using vnodes and DTYPE_VNODE
Umm....
> (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
"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?20030121185208.A82EB2A7EA>