Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jan 2003 13:32:25 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        phk@freebsd.org
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, "Alan L. Cox" <alc@imimic.com>, Peter Wemm <peter@wemm.org>, arch@freebsd.org
Subject:   Re: getsysfd() patch #1 (Re: Virtual memory question) 
Message-ID:  <Pine.NEB.3.96L.1030121132828.11405D-100000@fledge.watson.org>
In-Reply-To: <16711.1043173573@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

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

(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.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories



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?Pine.NEB.3.96L.1030121132828.11405D-100000>