[coreboot] Unifying IO accessor macros

[ron minnich]

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 at 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 at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20150218/19df7668/attachment.html>