[coreboot] Unifying IO accessor macros

David Hendricks dhendrix at google.com
Wed Feb 18 21:09:22 CET 2015


On Wed, Feb 18, 2015 at 8:49 AM, Alexandru Gagniuc <mr.nuke.me at gmail.com>
wrote:

> On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote:
> > As I have noted on http://review.coreboot.org/#/c/7924/ it's very
> > 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
> spent
> writing this email, you could have found out how to do it with coccinelle,
> and
> 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
> likely
> just copypasting code. In that case, I do want a barrier to protect you
> from
> 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
traction.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150218/65031a7e/attachment.html>


More information about the coreboot mailing list