[PATCH] drm/gem: Add new flink_to ioctl
chris at chris-wilson.co.uk
Thu Jul 8 09:37:20 PDT 2010
On Thu, 8 Jul 2010 12:14:28 -0400, Kristian HÃ¸gsberg <krh at bitplanet.net> wrote:
> On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard <keithp at keithp.com> wrote:
> > On Thu, Â 8 Jul 2010 11:23:25 -0400, Kristian HÃ¸gsberg <krh at 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.
Chris Wilson, Intel Open Source Technology Centre
More information about the dri-devel