From owner-freebsd-arch Tue Jan 14 19:16:21 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 E648537B401 for ; Tue, 14 Jan 2003 19:16:19 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E64543F13 for ; Tue, 14 Jan 2003 19:16:19 -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 h0F3GJ0i005443; Tue, 14 Jan 2003 19:16:19 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0F3GIe8005442; Tue, 14 Jan 2003 19:16:18 -0800 (PST) Date: Tue, 14 Jan 2003 19:16:18 -0800 (PST) From: Matthew Dillon Message-Id: <200301150316.h0F3GIe8005442@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: <20030114231736.DF9442A89E@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 :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message