Date: Wed, 15 Jan 2003 12:51:42 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> Cc: Terry Lambert <tlambert2@mindspring.com>, "Alan L. Cox" <alc@imimic.com>, arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301152051.h0FKpgxA009515@apollo.backplane.com> References: <20030115034234.A3A742A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
<dillon@backplane.com>
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?200301152051.h0FKpgxA009515>