From owner-freebsd-arch Tue Jan 21 19: 4:33 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35ADD37B401; Tue, 21 Jan 2003 19:04:31 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4E9D43E4A; Tue, 21 Jan 2003 19:04:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0M34T0i099695; Tue, 21 Jan 2003 19:04:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0M34TMB099694; Tue, 21 Jan 2003 19:04:29 -0800 (PST) Date: Tue, 21 Jan 2003 19:04:29 -0800 (PST) From: Matthew Dillon Message-Id: <200301220304.h0M34TMB099694@apollo.backplane.com> To: Peter Wemm Cc: Robert Watson , phk@FreeBSD.ORG, "Alan L. Cox" , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030121185208.A82EB2A7EA@canning.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> (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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message