Date: Tue, 14 Jan 2003 19:16:18 -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: <200301150316.h0F3GIe8005442@apollo.backplane.com> References: <20030114231736.DF9442A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Also, it gives you a handle to hold data while temporarily unmapped. eg:
:you can implement a small movable mapped window into a larger object. With
:MAP_ANON and /dev/zero, when you unmap the pages they are gone.
:
:Also, we could use one of these beasties as a backing store for malloc().
:Since the offset is persistent and has a sequence of page offsets it should
:avoid the map fragmentation.
That is a very interesting idea. fork() would be a problem though.
Still, I see a lot of possible uses for this sort of thing.
Communication between kernel and userland could use a VM Object like
this... consider kqueue and AIO operation that does not require copying
to and from userspace. Instead you implement a message queue with a
shared VM object and tell the kernel to go. This would allow a bunch of
I/O and/or kqueue requests to be collected together and then initiated
with a single system call, and events could be reported back on a
different VM Object.
(just brainstorming).
:> Another thing I would like to do is descriptor-based timers. So instead
:> of being limited to just the stupid itimers, or interfering with other
:> threads/libraries use of [i]timers, you can simply allocate your own by
:> getting a timer descriptor and then doing cool things with it, like
:> having it generate a custom signal or selecting on it or kqueue'ing on
:> it etc... it's something UNIX has needed for a long time actually.
:
:We use kqueue timers at work FWIW. Trying to use the system timers in some
:cases is painful, and the kqueue EVFILT_TIMER stuff (both on periodic and
:oneshot mode) is just damn convenient. Sure, it doesn't have the bells and
:whistles that you have commented out in sysfd.h, but what kqueue provides
:is exactly what we need. Allthough the features could be added to the
:already existing kqueue interface, I dont see much use for them - sys
:and virtual timebases are rather specialized and somewhat overkill for
:regular applications IMHO.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
Oh, don't get me wrong... the kqueue timers definitely fill a need.
They aren't complete, though.
-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?200301150316.h0F3GIe8005442>