Re: [PATCH 2/3] M68K: Use CONFIG_MMU not __uClinux__ to select m68knommucontributions
From: Greg Ungerer
Date: Thu Sep 02 2010 - 23:30:08 EST
Sam Ravnborg wrote:
On Thu, Sep 02, 2010 at 11:21:58AM +0100, David Howells wrote:
Use CONFIG_MMU not __uClinux__ to select m68knommu contributions as nothing in
the arch defines __uClinux__ for the build.
This patch was achieved by running the following three commands:
perl -pi -e 's/ifdef __uClinux__/ifndef CONFIG_MMU/' `find arch/m68k -name "*.[ch]"`
perl -pi -e 's/ifndef __uClinux__/ifdef CONFIG_MMU/' `find arch/m68k -name "*.[ch]"`
perl -pi -e 's!endif /[*] __uClinux__ [*]/!endif /* CONFIG_MMU */!' `find arch/m68k -name "*.[ch]"
Have you verified that this does not leak out
to the userspace headers?
We cannot use the CONFIG_ symbol to distingush between
the two variants in userspace.
This was exactly the reason why __uClinux__ was used
in the first place. But I hope Geert/Greg has fixed
it up so all exported headers are the same so that
this patch is OK.
Well, I don't quite have them all fixed yet. I have been working
through them, merging the separate files, and getting rid of the
use of __uClinux__ where ever I can. Most of the cases in David's
patch are the files I still have out-standing to merge back
together. The exceptions are param.h and sigcontext.h - and
they are a bit more tricky. They are user exported, and they
actually change data structures.
At first look I think it is OK - but your changelog
does not address this so wanted you to confirm this.
I don't have any problem with David's patch if we take out param.h
and sigcontext.h. But over time most will go away as I merge them
anyway.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@xxxxxxxxxxxx
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/