Thread (14 messages) 14 messages, 3 authors, 2013-03-29

Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch

From: Luis R. Rodriguez <hidden>
Date: 2013-03-28 23:25:42
Also in: cocci, dri-devel, lkml

On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall [off-list ref] wrote:
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
quoted
On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall [off-list ref] wrote:
quoted
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
quoted
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!
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help