From owner-freebsd-arch Tue Jan 21 20:24:46 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 1A9A737B401; Tue, 21 Jan 2003 20:24:45 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC72243EB2; Tue, 21 Jan 2003 20:24:44 -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 h0M4Od0i000392; Tue, 21 Jan 2003 20:24:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0M4OdZn000391; Tue, 21 Jan 2003 20:24:39 -0800 (PST) Date: Tue, 21 Jan 2003 20:24:39 -0800 (PST) From: Matthew Dillon Message-Id: <200301220424.h0M4OdZn000391@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: <20030122041546.393AF2A8A5@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 :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 Hmm. Well, the opengroup manual page for fattach() basically says that you fattach(filedes, path) to an existing file and operations on the file are then operations on filedes, but the manual page is specifically STREAM oriented. We could use it for other types of file descriptors but I'm somewhat worried about how error conditions would be detected... for a memory descriptor how do you know you are mmap()ing the memory descriptor rather then the file? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message