Date: Tue, 28 Oct 2003 10:10:34 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/ia64 sys_machdep.c src/sys/ia64/include sysarch.h Message-ID: <1067335833.42914.20.camel@herring.nlsystems.com> 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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1067335833.42914.20.camel>