On Wed, Jan 15, 2020 at 12:42:39PM +0000, Will Deacon wrote:

On Wed, Jan 15, 2020 at 12:07:03PM +0000, Mark Brown wrote:

quoted

tables like cpufeature.h that make it annoying to hold out of
tree, the bits that are going to change can just as well be
worked on incrementally as held out of tree entirely and having
the rest in means there's less friction doing that.

The usual downside that comes from merging patches with promises of fixing
them up later is that the motivating task gets marked as "done" somewhere,
the developer gets given something else to do and the updates never
materialise. That's not a dig at you; it's just the way these things tend
to work (I've certainly been on both sides of that coin).

It's certainly a way things can work, but it does assume that
there is an underlying motivating task that involves getting
things upstream which will cause people to do the additional work
rather than just wandering off and then potentially causing
someone else to redo the bit that was already done if they don't
notice the code in the list archives or spend time trying to
figure out if the original author will continue revising their
series.  We even had an awkward situation when I was at Linaro
where the original author of something we depended on was
continuing to work on their series but it was now a spare time
activity for them so progress was painfully slow, the worst of
both worlds.  The most common way this happens that I run into is
people implementing things for products who are doing the
upstreaming on the side.

It can also have the effect of discouraging people from trying to
do things in the first place, I know the likelyhood of scope
creep is one of the factors that influences how likely I am to
try to improve things I happen to notice while I'm working on
something else and I'm fairly sure other people make similar
assessments.

If there was an urgency to this, I'd suggest merging a form of Richard's
code, as it appears to solve the technical issue of credited entropy whilst
leaving some room for subsequent cleanup. However, I think that makes it
even less likely that anybody will come back to do the cleanup because the

I agree with your assessment of the likelyhood of cleanup, I
think an incomplete solution that doesn't credit entropy is more
robustly likely to get fixed since it causes an actual problem
that people will be motivated to fix as opposed to just being
ugly code.  I have no objection to merging Richard's
static_branch_likely() approach though.

code will be perfectly functional, so I'd prefer to wait for a complete
solution unless you think it's not achievable for 5.7.

It could happen but I wouldn't like to commit to getting
something in for v5.7, that's basically just a single release
given how near we are to the v5.6 merge window opening and I know
changes in the random code can sometimes take a while.