From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/gem: Add new flink_to ioctl Date: Thu, 08 Jul 2010 17:37:20 +0100 Message-ID: <89kc63$hd3ebf@fmsmga002.fm.intel.com> References: <1278602605-21728-1-git-send-email-krh@bitplanet.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1750671318==" Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 81A409EEF6 for ; Thu, 8 Jul 2010 09:37:25 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Keith Packard Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1750671318== Content-Type: text/plain On Thu, 8 Jul 2010 12:14:28 -0400, Kristian Høgsberg wrote: > On Thu, Jul 8, 2010 at 11:59 AM, Keith Packard wrote: > > On Thu,  8 Jul 2010 11:23:25 -0400, Kristian Høgsberg 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. -ickle -- Chris Wilson, Intel Open Source Technology Centre --===============1750671318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1750671318==--