Comment 18 for bug 868550

OK, now I think I understand your point of view.

If Linux kernel headers are not allowed to care at all what other non-
kernel headers may exist, then you are right, __linux__ should not be
referenced by the exported headers after unifdef processing.

This does open the way for __linux__ to have a private meaning inside
the kernel tree, and for us to do unifdef processing based on that.

Since this simplifies the change (and hence reduces the risk of
collateral damage), and since a few arches already do the same thing,
I'm now not strongly opposed to putting -D__linux__ in arch/arm/Makefile.

The I objection I had to that (building a non-Linux OS with a Linux
targeted compiler might require -U__linux__) is contrived, and I have
no real example for it.

Have I understood you correctly?

As you point out, some exportable userspace headers still need to be
cleaned up to use __linux__ in the appropriate way, and
scripts/headers_install.pl would need to be updated accordingly.
Since headers_install.pl is global, would that mean that -D__linux__
should also be global, in the top-level Makefile?

---Dave