On Mon, 2008-07-07 at 22:11 +0100, Hugh Dickins wrote: > Sorry, Andrew got the wrong pantomime: I was appearing in Aladdin > a couple of years ago, but this year I'm the Sleeping Beauty. > (Did I hear a grumble of dissent from the back stalls?)
No comment :-) > I don't find Dave's patch very handsome, but it gets the job done > so I'd better not carp. The ugliness in vm_get_page_prot is just > an inevitable consequence of growing beyond the traditional neat > pairing of VM_xxx flags with VM_MAYxxx flags, along with the way > that opaque pgprot_t type becomes occasionally tiresome, as such > opaque types do: I don't think there's a better way of handling > it than Dave has done. That was also my conclusion. It didn't look pretty but I couldn't come up with something prettier. > There is a little inconsistency, that arch_calc_vm_prot_bits > and arch_vm_get_page_prot just handle the exceptional flag (SAO), > whereas arch_validate_prot handles all of them; but I don't feel > so strongly about that to suggest resubmission. > > And regarding VM_SAO added to include/linux/mm.h in 3/6: although > it's odd to be weaving back and forth between arch-specific and > common, it's already the case that mman definitions and pgtable > definitions are arch-specific but mm.h common: I'm much happier > to have VM_SAO defined once there as Dave has it, than get into > arch-specific vm_flags. > > Is someone going to be asking for PROT_WC shortly? I'll definitely come with PROT_ENDIAN soon :-) (ie, some powerpc processors can have a per-page endian flag that when set causes all load/store instructions on this are to be byte-flipped, support for this feature has been requested for some time, and now I have the infrastructure to do it). Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
