Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch
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
Home |
Main Index |
Thread Index |
Old Index