Well, I say it again: it matters not. I don't care how we do it, some ox is going to get gored. The order is much less important than consistency. And ox are tasty. So let's gore one.
The problem for me is not that I have an opinion, but that people I respect so highly have different opinions. How can very smart people have different opinions? This can't be :-)
Somebody make a decision and go for it. Just make sure it's type safe so we can catch it when I get it backwards.
Sorry I have been absent, somehow I got unsubscribed and did not notice for a while ...
I think it's probably more important to get sparse working for coreboot than this order of arguments thing anyway ...
ron
On Wed Feb 18 2015 at 8:58:23 AM Alexandru Gagniuc mr.nuke.me@gmail.com wrote:
On Wednesday, February 18, 2015 08:23:08 AM Vadim Bendebury wrote:
On Wed, Feb 18, 2015 at 7:16 AM, Aaron Durbin via coreboot
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.
This is a great reason to keep those accessors, IMO it tramps other considerations voiced on this thread. Let's be consistent with other software systems.
Following that reasoning, we should switch to EFI style so we can better integrate vendorcode:
read32 -> LibVendorMemRead(..., AccessWidth32, ...)
Doing what other software stacks do without a real reason, and just because it's trendy...
Alex
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot