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.
Alex
On Wed, Feb 18, 2015 at 10:49 AM, Alexandru Gagniuc mr.nuke.me@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.
http://review.coreboot.org/8483
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.
Ok. A hurdle or a hoop. What's the point of adding more hoops? You still haven't made any counter-argument to the practicalness of being compatible with the software systems where coreboot gets contribution. You have an opinion, sure, but I haven't heard anything aside from "something is wrong".
The current landscape is:
coreboot is different than:
1. linux 2. uboot 3. libpayload 4. Anything using libpayload
Being different is not necessarily better. coreboot's usage is tiny in comparison to the first 2 projects listed.
-Aaron
On Wed, Feb 18, 2015 at 8:49 AM, Alexandru Gagniuc mr.nuke.me@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.
-
Aaron Durbin -
Alexandru Gagniuc -
David Hendricks