On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall <julia.lawall@xxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
