Re: [coreboot] RFC: coding style: "standard" defines

2016-02-10 Thread Alex G. 
On 02/08/2016 11:29 AM, Julius Werner wrote:
>>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote:
 2016-02-04 10:35 GMT+01:00 Patrick Georgi :
> during the review of some commits that are in the process of being
> upstreamed from Chrome OS, people noticed that chipset drivers like to
> define their own TRUE/FALSE defines (sometimes prefixed to), and I
> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
> be the house rules in some firmware communities.
 Seems like for the BIT defines, all variants are popular. Any
 objection with moving them to src/include instead of having various
 copies across the tree?
>>> How about something like src/include/please_dont_use.h ?
>>>
>> I don't know about that but I'd have no objection to a comment in the file
>> itself that these are vile constructs.
> 
> If we agree on what not to use, why not just fix it completely?
> coccinelle is great for that sort of thing.
> (For the record, I don't mind BIT(x) too much but I also prefer (1 <<
> x), since it's more consistent with multi-bit fields like (5 << x).)

Other than BITxx macros, really, what's the purpose of this? Sure,
standardization sounds great, but can anyone point to reasons why _not_
standardizing results in loss of productivity? As I've said before, we
do import code from other codebases, which oftentimes are not even
self-consistent. There's loss in productivity from being forced to
convert one style of bit macro to another.

Just from that, it seems that trying to "standardize" is a net loss.
Pretty code is useless when it's slow and clumsy to write.

Alex

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-08 Thread ron minnich 
makes sense to me.

On Mon, Feb 8, 2016 at 3:10 AM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:

> 2016-02-04 10:35 GMT+01:00 Patrick Georgi :
> > during the review of some commits that are in the process of being
> > upstreamed from Chrome OS, people noticed that chipset drivers like to
> > define their own TRUE/FALSE defines (sometimes prefixed to), and I
> > have seen a bunch of #define BIT{0-31} ..., too, because that seems to
> > be the house rules in some firmware communities.
> Seems like for the BIT defines, all variants are popular. Any
> objection with moving them to src/include instead of having various
> copies across the tree?
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-08 Thread Patrick Georgi via coreboot 
2016-02-04 10:35 GMT+01:00 Patrick Georgi :
> during the review of some commits that are in the process of being
> upstreamed from Chrome OS, people noticed that chipset drivers like to
> define their own TRUE/FALSE defines (sometimes prefixed to), and I
> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
> be the house rules in some firmware communities.
Seems like for the BIT defines, all variants are popular. Any
objection with moving them to src/include instead of having various
copies across the tree?


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-08 Thread Nico Huber 
On 08.02.2016 12:10, Patrick Georgi via coreboot wrote:
> 2016-02-04 10:35 GMT+01:00 Patrick Georgi :
>> during the review of some commits that are in the process of being
>> upstreamed from Chrome OS, people noticed that chipset drivers like to
>> define their own TRUE/FALSE defines (sometimes prefixed to), and I
>> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
>> be the house rules in some firmware communities.
> Seems like for the BIT defines, all variants are popular. Any
> objection with moving them to src/include instead of having various
> copies across the tree?
How about something like src/include/please_dont_use.h ?

Nico


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-08 Thread Julius Werner 
>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote:
>> > 2016-02-04 10:35 GMT+01:00 Patrick Georgi :
>> >> during the review of some commits that are in the process of being
>> >> upstreamed from Chrome OS, people noticed that chipset drivers like to
>> >> define their own TRUE/FALSE defines (sometimes prefixed to), and I
>> >> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
>> >> be the house rules in some firmware communities.
>> > Seems like for the BIT defines, all variants are popular. Any
>> > objection with moving them to src/include instead of having various
>> > copies across the tree?
>> How about something like src/include/please_dont_use.h ?
>>
> I don't know about that but I'd have no objection to a comment in the file
> itself that these are vile constructs.

If we agree on what not to use, why not just fix it completely?
coccinelle is great for that sort of thing.
(For the record, I don't mind BIT(x) too much but I also prefer (1 <<
x), since it's more consistent with multi-bit fields like (5 << x).)

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread Patrick Georgi via coreboot 
Hi all,

during the review of some commits that are in the process of being
upstreamed from Chrome OS, people noticed that chipset drivers like to
define their own TRUE/FALSE defines (sometimes prefixed to), and I
have seen a bunch of #define BIT{0-31} ..., too, because that seems to
be the house rules in some firmware communities.

I think we should seek uniformity here: decide on some style,
recommend it, clean up the tree to match, and help people stay
consistent through lint tests. What I don't know however is what that
style should look like.

So, two topics:

1. TRUE/FALSE
Do we want such defines? If so, TRUE/FALSE, or true/false, or
True/False, or ...?

2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
I don't think it makes sense to go for a single one of these (0x3ff is
certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
| BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
BIT16 and BIT(16).


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread Nico Huber 
On 04.02.2016 22:25, Patrick Georgi via coreboot wrote:
> 2016-02-04 22:22 GMT+01:00 Martin Roth :
>> I don't think we need redefinitions of TRUE/FALSE
> We have no canonical definitions for TRUE/FALSE right now.
> Contributions that use them (for whatever reason) tend to bring local
> copies, and that's what I'd like to avoid.
I don't like true/false definitions neither. If we have contributions
which bring them, well, we should factor it out during review.

Arguments against true/false definitions? It's C! As we know, in C,
everything but 0 is naturally true. While redefining true/false seems
to enhance readability, it breaks with this principle. That might not
be a problem if you write new code---you usually know how you want to
interpret true then. However if you just read code you might find a
condition like
  if (something == true)
So, I expect that this comparison is done in terms of the type of
`something` (and is only "true" if `something` evaluates to 1). Is it
like that? Well, I'm pretty sure it is. But having to think about it
is already too much IMO.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread ron minnich 
Nico, I agree with you completely: non-zero is true, zero false. It's C.
But I am starting now to feel like a dinosaur, b/c
"Oh, and I'm trying to hang with the cool kids and use bool :)" -- Rusty

It makes me want to start an emo coreboot programmer feed like this one:
https://twitter.com/kylor3n?lang=en
for those of us who have been using "C as it is spoken" for more than 5
years :-)

Seriously, though, I agree with you but ... the world may not :-)

ron



On Thu, Feb 4, 2016 at 2:01 PM Nico Huber  wrote:

> On 04.02.2016 22:25, Patrick Georgi via coreboot wrote:
> > 2016-02-04 22:22 GMT+01:00 Martin Roth :
> >> I don't think we need redefinitions of TRUE/FALSE
> > We have no canonical definitions for TRUE/FALSE right now.
> > Contributions that use them (for whatever reason) tend to bring local
> > copies, and that's what I'd like to avoid.
> I don't like true/false definitions neither. If we have contributions
> which bring them, well, we should factor it out during review.
>
> Arguments against true/false definitions? It's C! As we know, in C,
> everything but 0 is naturally true. While redefining true/false seems
> to enhance readability, it breaks with this principle. That might not
> be a problem if you write new code---you usually know how you want to
> interpret true then. However if you just read code you might find a
> condition like
>   if (something == true)
> So, I expect that this comparison is done in terms of the type of
> `something` (and is only "true" if `something` evaluates to 1). Is it
> like that? Well, I'm pretty sure it is. But having to think about it
> is already too much IMO.
>
> Nico
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread Timothy Pearson 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/2016 04:22 PM, ron minnich wrote:
> Nico, I agree with you completely: non-zero is true, zero false. It's C.
> But I am starting now to feel like a dinosaur, b/c
> "Oh, and I'm trying to hang with the cool kids and use bool :)" -- Rusty
> 
> It makes me want to start an emo coreboot programmer feed like this
> one: https://twitter.com/kylor3n?lang=en
> for those of us who have been using "C as it is spoken" for more than 5
> years :-)
> 
> Seriously, though, I agree with you but ... the world may not :-)
> 
> ron

For the record, I agree with you here.  "non-zero is true, zero false".

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWs9FWAAoJEK+E3vEXDOFbBy8H/j3UucwN4PfpNP+5RdngJ0o8
rJJvLJr6QnmR14DnnW+IIJ+4cXj+jiv+RaI+TbiC37joZXLzS5iyK8xC9rRurdrV
bUTVBpMVVHNevzDF21tho5ZeH8TE75Ho1hpLqMW3XFjw4hT191K39pNCR2S++zvC
B3OsF1As3hsO/Cw2QGwSXLAJBP7o6Tbth00fTYp4NFGo2VBFEBAs+1MA8artEbtv
3BiYS2VwGtfKlnQAKzve+rbc7TLWWJWYAWF1Zc7eJGXHFeDQ2gl+6m7euKsrcubd
mFOOndPuRtqGi4YBVJHZRPsIqgMxqDCuebc3DkqPrVGbUQouWqwhY4PNOT13bak=
=/BTX
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread Martin Roth 
I don't think we need redefinitions of TRUE/FALSE

Ron's argument against using BIT(16) makes sense to me.

I don't have a problem with BIT16, 0x1, or (1 << 16) but
#define VENDOR_BIT_16 0x1 seems like overkill.


I'd really generally prefer some good definitions though
  instead of write(BIT16) I'd really like to see:
  #define ENABLE_FEATURE BIT16
  write(ENABLE_FEATURE)

I know that at times we don't have good documentation about what the
values actually do, but we've got a lot of magic numbers throughout
our code.

How would people feel about adding something to the coding guide to
avoid magic numbers?

Martin

On Thu, Feb 4, 2016 at 6:05 AM, ron minnich  wrote:
>
>
> On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot
>  wrote:
>>
>>
>>
>> 1. TRUE/FALSE
>> Do we want such defines? If so, TRUE/FALSE, or true/false, or
>> True/False, or ...?
>
>
> should we start using bool ...?
>>
>>
>> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
>> I don't think it makes sense to go for a single one of these (0x3ff is
>> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
>> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
>> BIT16 and BIT(16).
>>
>
> BIT16 is a constant. BIT(16) is a chance for things to go badly wrong, e.g.
> BIT(x-y) might produce some very strange problems. I kind of prefer the
> constant.
>
> ron
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread Vadim Bendebury 
On Thu, Feb 4, 2016 at 2:00 PM, Nico Huber  wrote:
> On 04.02.2016 22:25, Patrick Georgi via coreboot wrote:
>> 2016-02-04 22:22 GMT+01:00 Martin Roth :
>>> I don't think we need redefinitions of TRUE/FALSE
>> We have no canonical definitions for TRUE/FALSE right now.
>> Contributions that use them (for whatever reason) tend to bring local
>> copies, and that's what I'd like to avoid.
> I don't like true/false definitions neither. If we have contributions
> which bring them, well, we should factor it out during review.
>
> Arguments against true/false definitions? It's C! As we know, in C,
> everything but 0 is naturally true. While redefining true/false seems
> to enhance readability, it breaks with this principle. That might not
> be a problem if you write new code---you usually know how you want to
> interpret true then. However if you just read code you might find a
> condition like
>   if (something == true)

This of course brings another style point/suggestion: Boolean checks
should never involve comparing, it should be

if (something){}

or

if (!something){}

--vb


> So, I expect that this comparison is done in terms of the type of
> `something` (and is only "true" if `something` evaluates to 1). Is it
> like that? Well, I'm pretty sure it is. But having to think about it
> is already too much IMO.
>
> Nico
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread Patrick Georgi via coreboot 
2016-02-04 22:22 GMT+01:00 Martin Roth :
> I don't think we need redefinitions of TRUE/FALSE
We have no canonical definitions for TRUE/FALSE right now.
Contributions that use them (for whatever reason) tend to bring local
copies, and that's what I'd like to avoid.

> How would people feel about adding something to the coding guide to
> avoid magic numbers?
Make that a separate thread please :-)


Patrick

> On Thu, Feb 4, 2016 at 6:05 AM, ron minnich  wrote:
>>
>>
>> On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot
>>  wrote:
>>>
>>>
>>>
>>> 1. TRUE/FALSE
>>> Do we want such defines? If so, TRUE/FALSE, or true/false, or
>>> True/False, or ...?
>>
>>
>> should we start using bool ...?
>>>
>>>
>>> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
>>> I don't think it makes sense to go for a single one of these (0x3ff is
>>> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
>>> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
>>> BIT16 and BIT(16).
>>>
>>
>> BIT16 is a constant. BIT(16) is a chance for things to go badly wrong, e.g.
>> BIT(x-y) might produce some very strange problems. I kind of prefer the
>> constant.
>>
>> ron
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread ron minnich 
Vendors frequently ask us to use magic numbers, and have even requested at
times that we remove explanatory text.

We'll never get rid of magic numbers in this world :-(

ron

On Thu, Feb 4, 2016 at 1:25 PM Patrick Georgi  wrote:

> 2016-02-04 22:22 GMT+01:00 Martin Roth :
> > I don't think we need redefinitions of TRUE/FALSE
> We have no canonical definitions for TRUE/FALSE right now.
> Contributions that use them (for whatever reason) tend to bring local
> copies, and that's what I'd like to avoid.
>
> > How would people feel about adding something to the coding guide to
> > avoid magic numbers?
> Make that a separate thread please :-)
>
>
> Patrick
>
> > On Thu, Feb 4, 2016 at 6:05 AM, ron minnich  wrote:
> >>
> >>
> >> On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot
> >>  wrote:
> >>>
> >>>
> >>>
> >>> 1. TRUE/FALSE
> >>> Do we want such defines? If so, TRUE/FALSE, or true/false, or
> >>> True/False, or ...?
> >>
> >>
> >> should we start using bool ...?
> >>>
> >>>
> >>> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
> >>> I don't think it makes sense to go for a single one of these (0x3ff is
> >>> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
> >>> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
> >>> BIT16 and BIT(16).
> >>>
> >>
> >> BIT16 is a constant. BIT(16) is a chance for things to go badly wrong,
> e.g.
> >> BIT(x-y) might produce some very strange problems. I kind of prefer the
> >> constant.
> >>
> >> ron
> >>
> >> --
> >> coreboot mailing list: coreboot@coreboot.org
> >> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread Nico Huber 
On 04.02.2016 10:35, Patrick Georgi via coreboot wrote:
> I think we should seek uniformity here: decide on some style,
> recommend it, clean up the tree to match, and help people stay
> consistent through lint tests.
That's a good idea.

> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
> I don't think it makes sense to go for a single one of these (0x3ff is
> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
> BIT16 and BIT(16).
I would prefer not to have definitions for single bits. Maybe it's just
the code that I've seen using this pattern, but I don't find it any way
readable. If there are more than three BITS in an expression, I lose
track which are set. So typography really isn't my domain, but I think
the problem is the dominant BIT prefix which makes all those BITS
look the same.

Another argument against BIT* and BIT(x) definitions: It encourages
programmers to split numbers into single bits. Something that I've seen
too often: A datasheet defines some single bits and some numbers in a
word. Let's say bits 30, 15, 8-5 and 1. What we get to review looks
like:
  something |= BIT30 | BIT15 | BIT8 | BIT6 | BIT1; // Welcome to hell!
Instead we could have:
  something |= (1 << 30) | (1 << 15) | (10 << 5) | (1 << 1); // is it
really 10?
(what I can't recall to have ever seen: a mix of BIT* with numbers)

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread Alex G. 
Hi there,

This seems pretty simple.

On 02/04/2016 01:35 AM, Patrick Georgi via coreboot wrote:
> Hi all,
> 
> during the review of some commits that are in the process of being
> upstreamed from Chrome OS, people noticed that chipset drivers like to
> define their own TRUE/FALSE defines (sometimes prefixed to), and I
> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
> be the house rules in some firmware communities.
> 
> I think we should seek uniformity here: decide on some style,
> recommend it, clean up the tree to match, and help people stay
> consistent through lint tests. What I don't know however is what that
> style should look like.
> 
> So, two topics:
> 
> 1. TRUE/FALSE
> Do we want such defines? If so, TRUE/FALSE, or true/false, or
> True/False, or ...?

Standardize on stdbool.h, bool, true, false. It's the logical choice.

> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
> I don't think it makes sense to go for a single one of these (0x3ff is
> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
> BIT16 and BIT(16).

BIT16, no. Who wants 64 defines? Seriously, this sort of stuff raises
blood pressure.

BIT(16), sure. Actually, I used this trick a while back on the allwinner
port. BIT(16) meant "just a bit", whereas (1 << 16) meant an enum
(usually also paired close to 2 << 16, 3 << 16, etc).

0x1 also fine. If it's in a list of defines, why not?

#define RON 0x8000
#define JOHN 0x1
#define MARY 0x2


We all know Chromium guys like to copy paste code from all over the
interwebs, and quite frankly, why make their lives harder with harsh
guidelines? These are small inconsistencies that I don't think bother
anyone too much.

Alex

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: coding style: "standard" defines

2016-02-04 Thread ron minnich 
On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:

>
>
> 1. TRUE/FALSE
> Do we want such defines? If so, TRUE/FALSE, or true/false, or
> True/False, or ...?
>

should we start using bool ...?

>
> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
> I don't think it makes sense to go for a single one of these (0x3ff is
> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
> BIT16 and BIT(16).
>
>
BIT16 is a constant. BIT(16) is a chance for things to go badly wrong, e.g.
BIT(x-y) might produce some very strange problems. I kind of prefer the
constant.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot