Re: CVS commit: xsrc/external/mit/libpciaccess/dist/src

2012-11-04 Thread Alan Barrett 

On Fri, 02 Nov 2012, David Young wrote:

Modified Files:
xsrc/external/mit/libpciaccess/dist/src: common_interface.c

Log Message:
Remove useless extra const in const sometype const * var = value;.
Foundusing clang -Wduplicate-decl-specifier.


Maybe 'const sometype * const var' was intended, i.e., a single
assignment semantic?  I've probably mistyped that myself several times.


The variable is assigned only once, so that would work,
but it's in a small block where I don't think it would add any clarity.

--apb (Alan Barrett)

Re: CVS commit: xsrc/external/mit/libpciaccess/dist/src

2012-11-04 Thread David Laight 
On Sun, Nov 04, 2012 at 08:44:01AM +0200, Alan Barrett wrote:
 On Fri, 02 Nov 2012, David Young wrote:
 Modified Files:
 xsrc/external/mit/libpciaccess/dist/src: common_interface.c
 
 Log Message:
 Remove useless extra const in const sometype const * var = value;.
 Foundusing clang -Wduplicate-decl-specifier.
 
 Maybe 'const sometype * const var' was intended, i.e., a single
 assignment semantic?  I've probably mistyped that myself several times.
 
 The variable is assigned only once, so that would work,
 but it's in a small block where I don't think it would add any clarity.

Personally I almost never mark variables 'const', the only I initialise
in their declarations (at the top of a function) are probably almost
always never chaned (well maybe execpt default error values).

Marking function parameters 'const' is also pointless, some compilers
verify that the definition in the headers file matches - which is
partitularly pointless since the called object code isn't required
to avoid modifying the argument memory/register (which might sometimes
be a useful optimistation).

David

-- 
David Laight: da...@l8s.co.uk

Re: CVS commit: xsrc/external/mit/libpciaccess/dist/src

2012-11-04 Thread Matt Thomas 

On Nov 4, 2012, at 2:26 AM, David Laight wrote:

 Personally I almost never mark variables 'const', the only I initialise
 in their declarations (at the top of a function) are probably almost
 always never chaned (well maybe execpt default error values).

Personally, I always mark variable as const if I don't expect its value to 
change since that documents that expectation.  This is especially true for 
pointers:

const struct foo_softc * const sc = ifp-if_softc;

Once nice side effect is that it catches errors like:

if (sc = NULL) {
}

Re: CVS commit: src/sys/arch/sparc/sparc

2012-11-04 Thread Chuck Silvers 
On Sun, Nov 04, 2012 at 01:35:04PM +1100, matthew green wrote:
 
  Module Name:src
  Committed By:   chs
  Date:   Sun Nov  4 00:32:47 UTC 2012
  
  Modified Files:
  src/sys/arch/sparc/sparc: locore.s pmap.c
  
  Log Message:
  in cpu_switchto(), remove the MP-unsafe code to mark a pmap active on a CPU,
  pmap_activate() already does this.  add MP locking to pmap_activate()
  and pmap_deactivate().  move flushing of user windows and virtual caches
  from pamp_activate() to pmap_deactivate().
 
 
 hmm.  this makes pmap_deactivate() do things in UP that weren't being
 done before at all.  switching to/from kernel/lwp for the same lwp will
 now be flushing the ctx every time.  that seems suboptimal?

do you just mean that I should have left the #ifdef MULTIPROCESSOR
around the sp_tlb_flush()?  or something more than that?


 we should really update PMAP_LOCK() to not be kernel lock.

agreed.

beyond that, there's still plenty of room for improvement on most platforms.
I think the best example in our tree at this point is the x86 scheme
of deferring the MMU-switch work to points where we're actually about to
reference user mappings, eg. returning to user mode, copyin/copyout, etc.


-Chuck