Non-SFI mode: Clean up macros of base/ and ipc/ libraries for nacl_helper_nonsfi.

Non-SFI mode: Clean up macros of base/ and ipc/ libraries for nacl_helper_nonsfi.

Now, OS_NACL_SFI and OS_NACL_NONSFI are introduced to build/build_config.h, and these are preferred to __native_client_nonsfi__ and OS_NACL combination.

BUG=358465
TEST=Ran trybots.

Committed: https://crrev.com/853d6084e2f55a046ca7e3cc0ec427a26587f938
Cr-Commit-Position: refs/heads/master@{#302907}

[hidehiko, 2014-11-04 11:36:30]

hidehiko@chromium.org changed reviewers:
+ dmichael@chromium.org, mdempsky@chromium.org, mseaborn@chromium.org,
thestig@chromium.org

[hidehiko, 2014-11-04 11:36:30]

Thank you for review in advance!

Mark, could you review this from the project point of view?
Lei, could you review this as an OWNER of base/...?
Dave, could you review this as an NaCl familiar OWNER of ipc/...?
Matthew, could you review this from the security point of view?

- hidehiko

[dmichael (off chromium), 2014-11-04 17:46:51]

This feels like it ought to be two CLs. The OS_NACL_NONSFI part is definitely
good and should be an easy one to land by itself. Without knowing too much about
it, the MSG_TRUNC and MSG_CTRUNC part feels distinct and might e.g. be more
likely to need reverted.

Otherwise, it looks good.

[mdempsky, 2014-11-04 22:40:35]

lgtm for security, thanks!

[Mark Seaborn, 2014-11-05 00:31:57]

On 2014/11/04 17:46:51, dmichael wrote:
> This feels like it ought to be two CLs. The OS_NACL_NONSFI part is definitely
> good and should be an easy one to land by itself. Without knowing too much
about
> it, the MSG_TRUNC and MSG_CTRUNC part feels distinct and might e.g. be more
> likely to need reverted.
> 
> Otherwise, it looks good.

LGTM.  I agree -- it would be better to do the MSG_TRUNC part as a separate
change.

[hidehiko, 2014-11-05 13:02:04]

On 2014/11/05 00:31:57, Mark Seaborn wrote:
> On 2014/11/04 17:46:51, dmichael wrote:
> > This feels like it ought to be two CLs. The OS_NACL_NONSFI part is
definitely
> > good and should be an easy one to land by itself. Without knowing too much
> about
> > it, the MSG_TRUNC and MSG_CTRUNC part feels distinct and might e.g. be more
> > likely to need reverted.
> > 
> > Otherwise, it looks good.
> 
> LGTM.  I agree -- it would be better to do the MSG_TRUNC part as a separate
> change.

Thank you for review.
I reverted MSG_TRUNC parts from this CL, so now this is only for macro clean up.
I'll send another CL to enable MSG_TRUNC related code after this is landed,
because it trivially conflicts with this CL.

PTAL.
- hidehiko

[Mark Seaborn, 2014-11-05 14:50:55]

LGTM

[dmichael (off chromium), 2014-11-05 16:19:29]

lgtm

[Lei Zhang, 2014-11-05 22:22:09]

The CQ bit was checked by thestig@chromium.org

[Lei Zhang, 2014-11-05 22:22:10]

lgtm

[commit-bot: I haz the power, 2014-11-05 22:24:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/704513003/20001

[commit-bot: I haz the power, 2014-11-05 23:52:12]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2014-11-05 23:52:41]

Patchset 2 (id:??) landed as
https://crrev.com/853d6084e2f55a046ca7e3cc0ec427a26587f938
Cr-Commit-Position: refs/heads/master@{#302907}