libdrm, memory manager

[Keith W. <ke...@tu...>]

Dave,

I'm starting to put some flesh on the bones of this thing, and I'm 
wondering about some aspects of situating it in libdrm.

Specifically, things like initialization and dealing with 
hardware-specific quirks.  As it stands, there's no way I know of to put 
hardware-specific code into the libdrm userspace.

Consider the memory manager needs some sort of hook into hardware, say 
to emit a fence for synchronization.  Currently that's done differently 
on all each platform with some combination of device ioctls, numbers in 
sareas, etc.

What isn't clear is how that can continue if the memory manager is in 
libdrm - it could only work if each client of libdrm had that kludgy 
mess of code available for each possible hardware platform and were able 
to plug it into libdrm as callbacks.

Or perhaps if libdrm were to acquire the ability to load a sub-driver 
for each piece of hardware, or had all of them built in?

Or finally, if things like setting and testing for fences were all to be 
re-implemented hardware independently, using device-independent ioctls. 
  Even then, for the fence example, you'd like to have a new field in 
the device-independent part of the sarea so that you could identify some 
expired fences without issuing an ioctl...

So the choices seem to be:
	- all libdrm clients know about device-specific ioctls
	- libdrm learns about device-specific ioctls (or grows a sub-driver model)
	- functionality required by libdrm is made available as 
device-independent ioctls

The above applies to sarea values as well as ioctls...

Any thoughts?

Keith