Nick Hudson wrote: > On Wednesday 11 November 2009 17:03:17 Christoph Egger wrote: >> Nick Hudson wrote: >>> Module Name: src >>> Committed By: skrll >>> Date: Wed Nov 11 16:08:32 UTC 2009 >>> >>> Modified Files: >>> src/sys/arch/hp700/hp700: mainbus.c >>> src/sys/arch/hppa/hppa: pmap.c >>> src/sys/arch/hppa/include: pmap.h >>> >>> Log Message: >>> Use the new flags argument to pmap_kenter_pa for PMAP_NOCACHE. >>> >>> >>> +/* >>> + * MD flags that we use for pmap_kenter_pa: >>> + */ >> PMAP_NOCACHE is also documented for pmap_enter(9). > > but hp700 / hppa doesn't use it for pmap_enter hence the comment. > >>> +#define PMAP_NOCACHE 0x01 /* set the non-cacheable bit */ >>> + >> Please keep the MD value within PMAP_MD_MASK >> (defined in sys/uvm/uvm_pmap.h) >> so that new MI flags won't conflict. > > hmm, sys/uvm/uvm_pmap.h needs an update or your change is < 10% complete, or > both. > > /* > * Flags passed to pmap_enter(). Note the bottom 3 bits are VM_PROT_* > * bits, used to indicate the access type that was made (to seed modified > * and referenced information). > * > * Flags marked [PA] are for pmap_kenter_pa() only. Flags marked [BOTH] > * apply to pmap_kenter_pa() and pmap_enter(). All other flags are valid > * for pmap_enter() only. > */ > #define PMAP_WIRED 0x00000010 /* wired mapping */ > #define PMAP_CANFAIL 0x00000020 /* can fail if resource shortage */ > #if defined(PMAP_ENABLE_PMAP_KMPAGE) > #define PMAP_KMPAGE 0x00000040 /* [PA] page used for kernel memory */ > #else > #define PMAP_KMPAGE 0x00000000 > #endif /* PMAP_ENABLE_PMAP_KMPAGE */ > > #define PMAP_MD_MASK 0xff000000 /* Machine-dependent bits */ > > Shouldn't all PMAP_* flags be passed in the flags argument? Your changes > didn't do any of that, afaict.
Yes, they should do. But all ports need to update their pmap_enter/pmap_kenter_pa implementations along with adaptions in MI code in one go. If you update MD code and then MI code (or vice versa) the tree is in a broken state where nobody knows for how long. The comment can be updated w/o any problems. BTW: rmind already pointed out, PMAP_KMPAGE shouldn't be merged with VM_PROT_* any longer. > What am I missing? You might be interested in this thread: http://mail-index.netbsd.org/tech-kern/2009/04/16/msg004836.html >> Christoph > > Nick