Messages in this thread | | | From | David Mosberger <> | Date | Wed, 14 Apr 2004 12:02:58 -0700 | Subject | Re: [PATCH] (IA64) Fix ugly __[PS]* macros in <asm-ia64/pgtable.h> |
| |
>>>>> On Wed, 14 Apr 2004 19:46:03 +0100, Jamie Lokier <jamie@shareable.org> said:
Jamie> David Mosberger wrote: >> Huh? You haven't actually checked, have you?
Jamie> Yes I have. Quite thoroughly.
Then you should have noticed that drivers/char/mem.c is using PAGE_COPY. Various architecture-dependent code is also using PAGE_foo macros.
Jamie> In theory the Alpha can do exec-only pages, but it's __[PS]* Jamie> map always gives read permission when there's execute Jamie> permission. I'm not sure if there's a reason for that, or if Jamie> it just historically copied the i386 behaviour (Alpha was the Jamie> first port).
I know why: back in those days, GCC emitted code for nested C functions that assumed an executable stack. Also, Linus wasn't terribly eager to turn off execute-permission on data/stacks. Even on ia64 we started out that way, until I saw the error in my ways.
Jamie> I agree it is best to avoid namespace pollution. However Jamie> this is one area where ia64 sticks out because it's approach Jamie> is different from other ports. All of them except Alpha used Jamie> PAGE_* names to clarify the __[PS]* map, defining additional Jamie> names as needed.
The reality is that whenever you introduce a globally visible name that is not used on x86, there is a very definite risk that someone will use that same name and cause a conflict. We have had that happen several times and that's the reason I'm normally religious about prefixing all ia64-specific names with a "ia64_" or "IA64_" (yes, this makes code a bit uglier, but you can't have it both ways). Your argument that the Alpha and other ports are doing something different doesn't buy me anything. If the ia64 break builds, the Alpha maintainer won't fix it up for me, after all.
--david - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |