On Mon, Dec 16, 2002 at 12:49:27PM -0800, Linus Torvalds wrote: > > On Mon, 16 Dec 2002, Keith Whitwell wrote: > > > > > > 1) Provide a set of DRM APIs for PCI DMA buffers allocation. No > > > assumption about the buffer management is made and that is entirely left > > > to the DRM driver (which is free to put some in a linked list, map them > > > or whatever). In Linux they basically would be just a very thin wrapper > > > around pci_*_consistent routines. > > > > Is there an existing linux interface to these routines that could be used > > instead of adding code to the drm module? > > Not anything exported to user-land, no. [...] And from José's > email I got the strong vibe that he does NOT want to expose this buffer to > user space at all, he wants to just have a good interface to allocate them > in kernel land.
Exactly. > User land shouldn't access them much directly anyway, > since there are all the security issues with checking the commands etc. > > Inside the kernel, the interface _does_ exist, it's the > pci_alloc_consistent() routines that José already mentioned. > > > > 2) Have the current AGP allocation and memory mapping APIs available for > > > internal drive usage, instead of just an IOCTL interface for X usage. > > > > I don't understand what you're suggesting by this. > > It sounds to me like José wants to move the management entirely into the > kernel, and not map anything in user space at all. That's right. > Which makes sense, > since user space really can't generally safely be allowed to touch it > anyway. Security is not as big reason as better code organization since X is the only user space application allowed to touch though functions and already has root priveleges in the first place. > I personally like _not_ exporting stuff between user<->kernel, because > that layer between the two always ends up being a friction point. > Especially if it doesn't have very specific and well-defined behaviour > that leaves nothing open for playing games. > > So in that sense I think I like what José suggests, if I understand it > correctly (leave the very specific DRM_IOCTL_DMA things as the main way to > do everything, and phase out the "user-kernel-assisted allocation" part > and do all of that in-kernel - avoiding one "generic" interface that has > already been mis-used. You've summed it very well in a single paragraph! I'm glad that there is a good agreement of all those who replyed so far. I'll use the Mach64 branch as testbed for this. I'll try to avoid touching the existing DRM API as much as possible (in principle the only necessary changes will be to expose some APIs to the DRM itself in a suitable fashion) to avoid any side-effects. I'll present a patch to this list for further discussion when I get it implemented (which I add that will take a while as I'm very busy with other ATM). José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
