Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753955Ab3C1SZk (ORCPT ); Thu, 28 Mar 2013 14:25:40 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:63537 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750909Ab3C1SZg (ORCPT ); Thu, 28 Mar 2013 14:25:36 -0400 MIME-Version: 1.0 In-Reply-To: References: <1364472270-9297-1-git-send-email-mcgrof@do-not-panic.com> <20130328083943.01e61b4b@jbarnes-desktop> From: "Luis R. Rodriguez" Date: Thu, 28 Mar 2013 11:25:11 -0700 X-Google-Sender-Auth: SOL9FrBUA625IMOo5S4GpTuSuYU Message-ID: Subject: Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch To: Julia Lawall Cc: Jesse Barnes , florianschandinat , linux-fbdev , dri-devel@lists.freedesktop.org, "backports@vger.kernel.org" , cocci@systeme.lip6.fr, "linux-kernel@vger.kernel.org" , "rodrigo.vivi" , Daniel Vetter , "rafael.j.wysocki" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1807 Lines: 39 On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall wrote: > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: >> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the >> upstream fb patch is not accepted. If it is accepted we would not need >> this at all! >> >> > Then I guess there would be a similar rule for the false case? >> >> Nope, see that's the proactive strategy taken by the static inline and >> hence the patch. compat would have a static inline for both cases, and >> for the false case it'd be a no-op. If accepted upstream though then >> we would not need any changes for this collateral evolution. However >> *spotting* these collateral evolutions and giving you SmPL for them as >> a proactive strategy might be good given that if these type of patches >> are indeed welcomed upstream we'd then be able to address these as >> secondary steps. If they are not accepted then indeed we'd use them to >> backport that collateral evolution through both compat (adds the >> static inlines) and compat-drivers (the SmPL). > > Probably I am missing something, since I haven't looked at the code in > detail, bu wouldn't it be nicer to have a function call for the false > case, if there is a function call for the true case? Yes, and indeed we have that, its the same function call, in the negative case its a no-op, in the newer kernels it wraps to modifying the element as in the original code. > In looking at the > code, one could wonder why things are not done in a parallel way. Not sure I get this. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/