From owner-freebsd-arch Wed Jan 15 12:51: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 5D13137B401 for ; Wed, 15 Jan 2003 12:51:44 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D38BC43E4A for ; Wed, 15 Jan 2003 12:51:43 -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 h0FKph0i009516; Wed, 15 Jan 2003 12:51:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0FKpgxA009515; Wed, 15 Jan 2003 12:51:42 -0800 (PST) Date: Wed, 15 Jan 2003 12:51:42 -0800 (PST) From: Matthew Dillon Message-Id: <200301152051.h0FKpgxA009515@apollo.backplane.com> To: Peter Wemm Cc: Terry Lambert , "Alan L. Cox" , arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030115034234.A3A742A89E@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 think we've established the usefulness of a VM Object descriptor. Now what about the system call API? At the moment I have: fd = getsysfd(int type, off_t size); I'm thinking of making it a more generic filesystem-optional rendezvous. But it would not work like a FIFO. Instead you would simply create a normal file and specify it. The normal file would only be used as a placemarker for the system descriptor to allow rendezvous (which is probably how FIFO should have been done in the first place, since adding type bits to the stat/inode is not extensible). int getsysfd(int type, int xfd, int64_t data) The file would only be used as a placemarker. i.e. for SYSFD_MEMORY the storage is in the VM Object which is NOT associated with the file in any way other then to serve as a rendezvous. The filesystem rendezvous would be optional, you could specify -1 for xfd. If you specify xfd you would be able to close() it immediate after the getsysfd() call. Example useage: xfd = open("/tmp/fubar", O_CREAT, 0666); memfd = getsysfd(SYSFD_MEMORY, xfd, 1024*1024); Or: memfd = getsysfd(SYSFD_MEMORY, -1, 1024*1024); This covers the basic SYSFD types that I would like to implement... SYSFD_MEMORY, SYSFD_MSGQ (a properly implemented multi-target message queue, something we sorely need), and SYSFD_TIMER (sophisticated timer support). memfd = getsysfd(SYSFD_MEMORY, opt_fd, object_size) timerfd = getsysfd(SYSFD_TIMER, opt_fd, timer_type_and_initial_count) msgqfd = getsysfd(SYSFD_MSGQ, opt_fd, my_target_identifier) I considered adding a path argument to getsysfd() but I think that would be overkill. We might want to add a separate flags argument, though: int getsysfd(int type, int xfd, int flags, int64_t data) instead of: int getsysfd(int type, int xfd, int64_t data) So, remember, this particular debate should be about the system call API to be sure it covers expected needs. Do we have enough arguments? Do we need more? Do we need less? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message