From owner-cvs-src@FreeBSD.ORG Tue Oct 28 02:10:48 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 962F316A4CE; Tue, 28 Oct 2003 02:10:48 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id F285843FE5; Tue, 28 Oct 2003 02:10:46 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) h9SAAYpA046453; Tue, 28 Oct 2003 10:10:34 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Marcel Moolenaar In-Reply-To: <20031028092719.GA44213@dhcp01.pn.xcllnt.net> References: <200310272254.h9RMsZFN027412@repoman.freebsd.org> <1067332169.42914.3.camel@herring.nlsystems.com> <20031028092719.GA44213@dhcp01.pn.xcllnt.net> Content-Type: text/plain Message-Id: <1067335833.42914.20.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 28 Oct 2003 10:10:34 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on herring.nlsystems.com cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/ia64 sys_machdep.c src/sys/ia64/include sysarch.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 10:10:48 -0000 On Tue, 2003-10-28 at 09:27, Marcel Moolenaar wrote: > On Tue, Oct 28, 2003 at 09:09:29AM +0000, Doug Rabson wrote: > > Shouldn't there some kind of access control here? It appears as if > > anyone at all can do inx/outx. > > Eventually, yes. There's a possibility that I remove these. The X > server needs to be able to mmap uncachable memory for access to > the hardware. This could also be used to do I/O. The only thing the > kernel needs to export is the base of the memory mapped I/O space > with sysctl in that case. > > Note that this affects the VM and PMAP interfaces :-( Right. I seem to remember that the linux kernel makes it fairly easy to map pages with specific access modes into user space. Possibly we could get away with defining new VM_PROT_ flags, e.g.: #define VM_PROT_UNCACHED 0x10 #define VM_PROT_WRITECOMBINED 0x20 Apart from that, you could either add flags to mmap(2) or define a mmap entry point for /dev/io. Doing it via /dev/io gives you the access control too - the X server opens /dev/io while it has elevated permissions and then drops back to user credentials. > > > Also, I have a vague feeling that the > > Linux kernel manages to support userland inx/outx without system calls - > > if so, how do they do that? > > I think mmap is used for that as well. I can't see any specific mmap flags for uncached pages but my linux sources are quite old (2.5.66). I don't have the time to dig around in the latest kernel and glibc sources today, unfortunately. > > > Possibly with modern hardware the cost of the bus transaction dwarfs the > > cost of doing a system call so perhaps it doesn't matter. > > The sysarch approach is not optimal. I don't think it's very performance > critical. Modern graphics hardware is memory mapped anyway. Indeed. In fact the best approach for modern hardware is to use kernel-mediated DMA transfers. This is how the 3D drivers work and its likely to be used by the 2D drivers more and more over time.