Re: [PATCH] drm/gem: Add new flink_to ioctl

From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/gem: Add new flink_to ioctl
Date: Thu, 8 Jul 2010 09:49:26 -0700	[thread overview]
Message-ID: <20100708094926.16bbc3e9@virtuousgeek.org> (raw)
In-Reply-To: <89kc63$hd3ebf@fmsmga002.fm.intel.com>

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...

-- 
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel