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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1067335833.42914.20.camel>