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.
Exporting something shouldn't be hard, and it might make sense to export
it _independently_ of any DRM code, since the problem itself should be
pretty generic (it does depend on the device though - different PCI
segments may see different memory ranges on some of the more exotic
hardware out there).
However, I don't see any particularly sane user-level interface. Doing
something like
fd = open("/proc/bus/pci/00/07.1", O_RDWR);
mmap( .. fd );
would be possible, but sucky from an interface standpoint. 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. 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. Which makes sense,
since user space really can't generally safely be allowed to touch it
anyway.
Doing it in the kernel would imply having a few more drm library
functions, it shouldn't be too bad.
> Backward compatiblity means that old X servers and old 3d clients work with
> new versions of the kernel modules -- this means that you can't really remove
> API's... But I guess you can turn them into noops as long as things like
> DRM_IOCTL_DMA still work as expected...
You could make the user-level mappings do nothing (or maybe just act as a
hint to get the sizes for memory management, things like that), and DRM
internally would just ignore them and use the memory it managed on its
own.
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.
Linus
-------------------------------------------------------
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
