Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754251Ab3C1XZm (ORCPT ); Thu, 28 Mar 2013 19:25:42 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:65369 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753469Ab3C1XZd (ORCPT ); Thu, 28 Mar 2013 19:25:33 -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 16:25:10 -0700 X-Google-Sender-Auth: uTOsHumbSUFClPJUOGP9uA87lo0 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: 2500 Lines: 51 On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall wrote: > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote: > >> 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. > > I looked in today's linux-next, and there seems to be only one > initialization of this field, to true, and one test of this field. So > perhaps the case for setting the field to false just isn't needed. Oh sorry now I get what you mean! I thought about this -- and yes I decided to not add a bool false setting for the structure field given that the assumption is this would not be something dynamic, and data structure would be kzalloc()'d so by default they are 0. 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/