On Wed, Feb 18, 2015 at 8:49 AM, Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
On Wednesday, February 18, 2015 09:16:07 AM Aaron
As I have noted on
short sighted to go this route. In assembling a coreboot stack (which
includes libpayload and the payload itself) the code usually comes
from different software systems. Those include libpayload, linux
kernel, u-boot, etc. They all have the write(val, addr) semantics. I
see no good reason to artificially erect an ever present barrier for
integrating code into a coreboot system.
As Patrick already said, compared to the total effort to integrate external
sources, the issue of argument order is insignificant. In the time you
writing this email, you could have found out how to do it with coccinelle,
could have applied it to any number of sources.
Alex, you've clearly stated your opinion
you've not justified a reason
for keeping the barrier.
If you think that something as simple as this is a barrier, then you're
just copypasting code. In that case, I do want a barrier to protect you
yourself, and from putting up code that was no reviewed in its entirety.
Really, it's not a barrier.
I don't think this argument makes sense for code that is being actively
developed in other code bases and imported into coreboot. Of course, if
you're importing stable code and don't expect much churn, tidying things up
is a fine idea. But increasing deltas while a project is still under active
development only serves to make integration and maintenance efforts more
troublesome and prone to error. It's not a productive use of anyone's time
when there are real bugs to solve.
Vendors often have code which they have already qualified and are
understandably reluctant to make any changes to it, even trivial aesthetic
ones. I'd like to make it easier for them to contribute directly to
coreboot, and throwing up artificial barriers does not help them gain
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.