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