On Thu, 08 Jul 2010 17:37:20 +0100 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, 8 Jul 2010 12:14:28 -0400, Kristian Høgsberg <krh@xxxxxxxxxxxxx> wrote: > > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard <keithp@xxxxxxxxxx> wrote: > > > On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg <krh@xxxxxxxxxxxxx> 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... -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
