From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 2/9] drm/i915: [sparse] don't use variable size arrays Date: Wed, 18 Apr 2012 11:05:29 +0200 Message-ID: <20120418090529.GG5315@phenom.ffwll.local> References: <1334610468-9274-1-git-send-email-ben@bwidawsk.net> <1334610468-9274-3-git-send-email-ben@bwidawsk.net> <20120417192035.5b3e58a4@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ey0-f177.google.com (mail-ey0-f177.google.com [209.85.215.177]) by gabe.freedesktop.org (Postfix) with ESMTP id D2074A0A72 for ; Wed, 18 Apr 2012 02:04:31 -0700 (PDT) Received: by eaak13 with SMTP id k13so1828116eaa.36 for ; Wed, 18 Apr 2012 02:04:31 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20120417192035.5b3e58a4@bwidawsk.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Ben Widawsky Cc: intel-gfx@lists.freedesktop.org, Ben Widawsky List-Id: intel-gfx@lists.freedesktop.org On Tue, Apr 17, 2012 at 07:20:35PM -0700, Ben Widawsky wrote: > On Tue, 17 Apr 2012 22:39:15 -0300 > Paulo Zanoni wrote: > > > 2012/4/16 Ben Widawsky : > > > Sparse doesn't like: > > > "error: bad constant expression" > > > > > > > > > I know you'll hate me for asking, but: how difficult is it to fix sparse? > > Adding those mallocs/frees increases the code complexity, making it > > harder to read... > > > > > > I don't consider this a bikeshed. I've always been "under the > impression" C99 was sort of taboo in the kernel. In this case > specifically, it's never a great idea to allocate an unknown amount of > stack space as it probably messes with some of the static tools and > such. > > In other words, I believe the right thing to do here is not to fix > sparse. Plus there is precedent in other drivers to fix this kind of > thing for sparse. I originally had this patch create an arbitrarily > large object on the stack and fail if the args_len was too big. I can > go back to that certainly if people prefer. I've picked up the first 2 patches of this series for -next, with a tiny bikeshed on the 2nd one. I've gotten stuck while reviewing the next one, I think it'd be good if we can quickly discuss these on irc. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48