On Thu, 08 Jul 2010 17:37:20 +0100 Chris Wilson chris@chris-wilson.co.uk wrote:
On Thu, 8 Jul 2010 12:14:28 -0400, Kristian Høgsberg krh@bitplanet.net wrote:
On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard keithp@keithp.com wrote:
On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg krh@bitplanet.net wrote:
- a mechanism to attach a binary blob to an flink_to buffer name. open_with_data returns the data. Userspace (typically libdrm) decides the layout and versioning of the blob and the contents will be chipset specific. it's an opaque blob to the kernel, which doesn't need to know about stride and formats etc.
Arbitrary binary blobs considered harmful? Even if the kernel doesn't need to know all of this data, having it in an explicit (versioned) format will protect applications from randomly mis-interpreting the data.
I talked with ickle about that and whether or not to include a version+format u32 for the data in the ioctl args. He convinced me that the kernel didn't need to know about the layout of the blob and that requiring by convention that the first u32 of the blob is the version+format u32 would suffice. I can go either way on this, but I guess I have a small preference for making it part of the ioctl args as you suggest.
I am not going to argue with someone who has been tackling the issue of protocol extensions for 25 years... ;-)
My argument was based around that the current system is designed as a directory of opaque objects and so the extended attributes should be kept opaque to the kernel as well and left open to interpretation by userland. What I am most unclear about is under which circumstances is this backchannel communication preferable to passing the extra information over the IPC that needs to be performed anyway in order to open a surface.
That's the part I had trouble with as well. Passing the blob through the kernel saves a little IPC but also seems unnecessary, and so rubs against my kernel minimalist side...