Date: Tue, 21 Jan 2003 20:24:39 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> 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: <200301220424.h0M4OdZn000391@apollo.backplane.com> References: <20030122041546.393AF2A8A5@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301220424.h0M4OdZn000391>