Re: CVS commit: src/usr.bin/sockstat

2020-08-26 Thread Simon Burge
"Christos Zoulas" wrote:

> Module Name:  src
> Committed By: christos
> Date: Wed Aug 26 22:57:56 UTC 2020
>
> Modified Files:
>
>   src/usr.bin/sockstat: Makefile sockstat.c
>
> Log Message:
>
> undo previous, now sockstat works without privs

Nice, thanks Christos!

Cheers,
Simon.


Re: CVS commit: src/usr.bin/make

2020-08-02 Thread Simon Burge
"Roland Illig" wrote:

> Module Name:  src
> Committed By: rillig
> Date: Sun Aug  2 09:43:22 UTC 2020
>
> Modified Files:
>
>   src/usr.bin/make: var.c
>
> Log Message:
>
> make(1): use shorter local variable names
>
> The c in cp was redundant since the context makes it obvious that this
> is a character pointer. In a tight loop where lots of characters are
> compared, every letter counts.

I don't understand the intent of this commit.  Are you saying the length
of a C variable name has some sort of impact on code execution speed?

Cheers,
Simon.


Re: CVS commit: src/sys/conf

2020-07-08 Thread Simon Burge
"Valeriy E. Ushakov" wrote:

> Module Name:  src
> Committed By: uwe
> Date: Wed Jul  8 19:39:22 UTC 2020
>
> Modified Files:
>
>   src/sys/conf: assym.mk
>
> Log Message:
>
> Drop -fstack-usage* from CFLAGS passed genassym.
> We don't want it to create a "-.su" file.

Thanks!

Cheers,
Simon.


Re: CVS commit: src/sys/arch/mips/cavium/dev

2020-06-26 Thread Simon Burge
Hi Rin,

Rin Okuyama wrote:

> Hi,
>
> On 2020/06/23 14:18, Simon Burge wrote:
> > Module Name:src
> > Committed By:   simonb
> > Date:   Tue Jun 23 05:18:43 UTC 2020
> > 
> > Modified Files:
> > src/sys/arch/mips/cavium/dev: octeon_uart.c
> > 
> > Log Message:
> > Add support for a very simple output-only console so early printf() can 
> > work.
> > Minor tweaks, remove some unused code.
> > 
> > 
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.8 -r1.9 src/sys/arch/mips/cavium/dev/octeon_uart.c
>
> Didn't you forget to ``cvs add octeon_uartvar.h''? Periodic build fails as:

Yep, indeed!  Added, thanks for pointing this out.

Cheers,
Simon.


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

2020-06-09 Thread Simon Burge
Simon Burge wrote:

> > > Module Name:  src
> > > Committed By: simonb
> > > Date: Tue Jun  9 06:18:01 UTC 2020
> > > 
> > > Modified Files:
> > >   src/sys/arch/mips/mips: mips_machdep.c
> > > 
> > > Log Message:
> > > If we are on a SiByte or Cavium CPU with an FPU, report as "built-in FPU"
> > > instead of saying it's an unknown FPU type.
> > > 
> > > XXX - add any other CPUs to this list?
> >
> > This seems to cause build errors for non mipsNN:
>
> Oops, will fix.  Thanks for reporting.

Fixed, thanks!

Cheers,
Simon.


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

2020-06-09 Thread Simon Burge
Izumi Tsutsui wrote:

> > Module Name:src
> > Committed By:   simonb
> > Date:   Tue Jun  9 06:18:01 UTC 2020
> > 
> > Modified Files:
> > src/sys/arch/mips/mips: mips_machdep.c
> > 
> > Log Message:
> > If we are on a SiByte or Cavium CPU with an FPU, report as "built-in FPU"
> > instead of saying it's an unknown FPU type.
> > 
> > XXX - add any other CPUs to this list?
>
> This seems to cause build errors for non mipsNN:

Oops, will fix.  Thanks for reporting.

Cheers,
Simon.


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

2020-06-06 Thread Simon Burge
"Kamil Rytarowski" wrote:

> Module Name:  src
> Committed By: kamil
> Date: Fri Jun  5 21:48:04 UTC 2020
>
> Modified Files:
>
>   src/sys/arch/x86/x86: cpu_rng.c
>
> Log Message:
>
> Change const unsigned to preprocessor define
>
> Fixes GCC -O0 build with the stack protector.

Surely a gcc bug?  This almost certainly needs an
/* XXX gcc stack protector -O0 bug */ comment and
possibly an entry in doc/HACKS as well otherwise
someone will come along later and de-uglify this
change.

Cheers,
Simon.


Re: CVS commit: src/lib/libcurses

2020-03-12 Thread Simon Burge
Hi Roy,

"Roy Marples" wrote:

> Module Name:  src
> Committed By: roy
> Date: Wed Mar 11 21:33:38 UTC 2020
>
> Modified Files:
>
>   src/lib/libcurses: initscr.c
>
> Log Message:
>
> curses: application should exit if initscr(3) fails
>
> POSIX defines this behaviour here:
> https://pubs.opengroup.org/onlinepubs/7908799/xcurses/initscr.html
>
> Partial fix for PR lib/23910

Can you please adjust the manpage to reflect this?  It currently says:

RETURN VALUES
 Functions returning pointers will return NULL if an error is detected.

Cheers,
Simon.


Re: CVS commit: src/sys/ufs/ufs

2020-02-26 Thread Simon Burge
"Maxime Villard" wrote:

> Module Name:  src
> Committed By: maxv
> Date: Wed Feb 26 18:00:12 UTC 2020
>
> Modified Files:
>
>   src/sys/ufs/ufs: ufs_vnops.c
>
> Log Message:
>
> Zero out the padding in 'd_namlen', to prevent info leaks. Same logic as
> ufs_makedirentry().

Is it cleaner to just call pool_cache_get() with PR_ZERO?

Cheers,
Simon.


Re: CVS commit: src/sys/kern

2020-01-21 Thread Simon Burge
"Christos Zoulas" wrote:

> Log Message:
>
> Don't crash if we are on a hippie trail, head full of zombie

+1 for any Australian references in a commit message :)

Cheers,
Simon.


Re: CVS commit: src/sys

2020-01-03 Thread Simon Burge
Hey Jason,

Jason Thorpe wrote:

> > On Jan 3, 2020, at 10:11 AM, Frank Kardel  wrote:
> > 
> > Hi Jason !
> > 
> > Could you please check that kmem using tools can cope with the missing 
> > _boottime symbol.
>
> Hey Frank... this should fix it:
>
>   $NetBSD: vmstat.c,v 1.231 2020/01/03 19:13:54 thorpej Exp $

Is it worth keeping the boottime symbol about so that a netbsd-9 vmstat
binary will still work with a -current kernel?  We could possibly wrap
boottime with a COMPAT_90 check too?.

Cheers,
Simon.


Re: CVS commit: src/sys

2020-01-03 Thread Simon Burge
Jason Thorpe wrote:

> > Is it worth keeping the boottime symbol about so that a netbsd-9 vmstat
> > binary will still work with a -current kernel?  We could possibly wrap
> > boottime with a COMPAT_90 check too?.
>
> Define "work".  A dummy symbol would have no valid contents.  I guess
> if you call that "work" then go ahead?
>
> The real problem here is that vmstat insists on finding the kernel
> symbols even if it's not going to use them, which is kind of silly.

That is indeed the silly(TM) thing.  Against a live kernel, it just
needs the boottime symbol to exist.  It uses the kern.boottime sysctl
to get the boottime from a live kernel.

Cheers,
Simon.


Re: Leak Sanitizer - how to suppress leaks

2019-09-12 Thread Simon Burge
Kamil Rytarowski wrote:

> I will revert it, but I am looking for a more generic approach.
>
> How about adding ifdef __NO_LEAKS like:
>
> #ifdef __NO_LEAKS
> free(3)?
> #endif
>
> And in lsan/asan/valgrind/etc checks use -D__NO_LEAKS.

Sorry if I'm missing something that has been already explained,
but why (practically) do we care about memory leaks for a utility
that is about to finish?

If we're doing some ugly #ifdef dance only when running the
sanitiser(s), then we haven't actually done anything to "fix"
the leak in the installed binaries so it seems that there was
no practical problem that we were trying to solve in the first
place.

Cheers,
Simon.


Re: CVS commit: src/usr.sbin/sysinst

2019-02-27 Thread Simon Burge
Martin Husemann wrote:

> On Wed, Feb 27, 2019 at 07:33:11PM +1100, Simon Burge wrote:
> > Looking at the code in question, is reducing the number of calls to
> > addstr() really something that needs to be optimised?  A simple
> > 
> > for (n = 0; n < win->ws_col; n++)
> > addstr("-");
> > 
> > is a lot easier to understand!
>
> Yeah I wondered that too - are they going to show up sequentially
> though, or will it all be defered untill the next update? I often use
> it via a 9600bps serial console and would like to avoid incremental
> changes.

addstr() just adjusts stdscr.  The line after these is:

refresh();

which will do the actual screen refresh/update.

Cheers,
Simon.


Re: CVS commit: src/usr.sbin/sysinst

2019-02-27 Thread Simon Burge
Martin Husemann wrote:

> On Tue, Feb 26, 2019 at 01:09:35PM +, Joerg Sonnenberger wrote:
> > Module Name:src
> > Committed By:   joerg
> > Date:   Tue Feb 26 13:09:35 UTC 2019
> > 
> > Modified Files:
> > src/usr.sbin/sysinst: run.c
> > 
> > Log Message:
> > Avoid string + int warning.
> > 
> > 
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.7 -r1.8 src/usr.sbin/sysinst/run.c
>
> What compiler warns and what are the exact details that make it warn?
> The idiom you used is IMHO extremely ugly, and I would usually rework
> it - but since I can't test that will likely break your build again.
>
> I would do: const char thirty_dashes[] = "---..---";
> and then const char * dashes = thirty_dashes +  m; addstr(dasches);

Looking at the code in question, is reducing the number of calls to
addstr() really something that needs to be optimised?  A simple

for (n = 0; n < win->ws_col; n++)
addstr("-");

is a lot easier to understand!

Cheers,
Simon.


Re: CVS commit: src/usr.bin/vmstat

2018-12-12 Thread Simon Burge
Hi Sevan,

Sevan Janiyan wrote:

> How about this?
>
> Index: usr.bin/vmstat/vmstat.1
> ===
> RCS file: /cvsroot/src/usr.bin/vmstat/vmstat.1,v
> retrieving revision 1.23
> diff -u -p -r1.23 vmstat.1
> --- usr.bin/vmstat/vmstat.1 13 Dec 2018 01:29:10 -  1.23
> +++ usr.bin/vmstat/vmstat.1 13 Dec 2018 02:50:00 -
> @@ -76,9 +76,17 @@ disk, trap, and CPU activity.
>  If
>  .Nm
>  is invoked without any options, it displays the summary of statistics since
> -boot and exits.
> +boot for all fields except memory and process statistic then exits.
> +The memory and process fields are live samples taken at the time
> +.Nm
> +was invoked in this implementation.
>  This is also referred to as the first line of
>  .Nm .
> +The
> +.Fl N ,
> +.Fl v ,
> +.Fl W
> +options adhere to this behaviour.
>  .Pp
>  The options are as follows:
>  .Bl -tag -width xxxhistname

While a bit wordier, I think that accurately describes the behaviour.
LGTM.

Cheers,
Simon.


Re: CVS commit: src/usr.bin/vmstat

2018-12-12 Thread Simon Burge
Hi Sevan,

"Sevan Janiyan" wrote:

> Module Name:  src
> Committed By: sevan
> Date: Thu Dec 13 01:29:11 UTC 2018
>
> Modified Files:
>
>   src/usr.bin/vmstat: vmstat.1
>
> Log Message:
>
> Describe what happens when you run vmstat witout any options aka the first 
> line
> of vmstat.

  +If
  +.Nm
  +is invoked without any options, it displays the summary of statistics since
  +boot and exits.

That's not true for the process and memory info though, right?  For
those two these are their current state, not a summary since boot.  Also
technically a few options don't change this behaviour either (at least
-M -N -v and -W?).

Not sure how we should document all this and be correct at the same
time. :)

Cheers,
Simon.


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

2018-08-08 Thread Simon Burge
Martin Husemann wrote:

> On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:
> > On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> > > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > > > Can we use aprint_debug instead?
> > > 
> > > It is not even usefull for general debugging IMHO.
> > > 
> > > Martin
> > 
> > I like the idea of removing the messages entirely. The code was hard to
> > read when I had to do it, and I didn't find those messages helpful.
>
> I meant: I like the way Simon changed it - it will not show up unless
> you are explicitly debugging exec stuff.

On top of what Martin said, there's a DEBUG_EXEC already in
sys/kern/kern_exec.c .  Do these messages still serve a purpose
now that the compat stuff is working?  I can't answer that!

Cheers,
Simon.


Re: CVS commit: src

2012-07-08 Thread Simon Burge
Mindaugas Rasiukevicius wrote:

  [ ... ]
 
 Log Message:
 
 Add MurmurHash2 -- a non-cryptographic hash function by Austin Appleby.
 The code is taken from the upstream and is in the public domain.

I'm curious why you've chosen MurmurHash2 instead of MurmurHash3 given the
known problems with MurmurHash2?  Also, should the filename have a 2 in
it?

Cheers,
Simon.


Re: CVS commit: src

2012-07-08 Thread Simon Burge
Mindaugas Rasiukevicius wrote:

 Simon Burge sim...@netbsd.org wrote:
  
[ ... ]
   
   Log Message:
   
   Add MurmurHash2 -- a non-cryptographic hash function by Austin Appleby.
   The code is taken from the upstream and is in the public domain.
  
  I'm curious why you've chosen MurmurHash2 instead of MurmurHash3 given the
  known problems with MurmurHash2?  Also, should the filename have a 2 in
  it?
 
 It meets my needs.

What are your needs?  I don't see this change discussed anywhere.

 Are you referring to the weakness when using 4-bytes?
 Anyway, that is why the file name does not have 2 in it, so that we could
 add MurmurHash3 as well.

That's completely different to the other hashes we have in the source
tree.  Can you rename the file so that it's consistent please?

Cheers,
Simon.


Re: CVS commit: src

2012-07-08 Thread Simon Burge
Mindaugas Rasiukevicius wrote:
 Simon Burge sim...@netbsd.org wrote:
  Mindaugas Rasiukevicius wrote:
   Simon Burge sim...@netbsd.org wrote:

  [ ... ]
 
 Log Message:
 
 Add MurmurHash2 -- a non-cryptographic hash function by Austin
 Appleby. The code is taken from the upstream and is in the public
 domain.

I'm curious why you've chosen MurmurHash2 instead of MurmurHash3
given the known problems with MurmurHash2?  Also, should the filename
have a 2 in it?
   
   It meets my needs.
  
  What are your needs?  I don't see this change discussed anywhere.
 
 I am going to use it in NPF as it shows better characteristics than
 Jenkins lookup3.  It is a very small function.

Thanks for the explaination.

   Are you referring to the weakness when using 4-bytes?
   Anyway, that is why the file name does not have 2 in it, so that we
   could add MurmurHash3 as well.
  
  That's completely different to the other hashes we have in the source
  tree.  Can you rename the file so that it's consistent please?
 
 Because other hashes use very different interface, with a context and
 common template in libc (rather horrible macros).  There is no need to
 create a directory for every different version of MurmurHash.  Rather
 undesirable, I would say.

I wasn't talking about creating a directory for every variant of murmur,
just putting each variant in a separate .c file.  Eg:

src/common/lib/libc/hash/murmurhash/murmurhash2.c
src/common/lib/libc/hash/murmurhash/murmurhash3.c

Or do you intend on adding other variants of murmur to the current .c
file if/when needed?

Cheers,
Simon.


Re: CVS commit: src

2012-07-08 Thread Simon Burge
Mindaugas Rasiukevicius wrote:
 Simon Burge sim...@netbsd.org wrote:
 Are you referring to the weakness when using 4-bytes?
 Anyway, that is why the file name does not have 2 in it, so that we
 could add MurmurHash3 as well.

That's completely different to the other hashes we have in the source
tree.  Can you rename the file so that it's consistent please?
   
   Because other hashes use very different interface, with a context and
   common template in libc (rather horrible macros).  There is no need to
   create a directory for every different version of MurmurHash.  Rather
   undesirable, I would say.
  
  I wasn't talking about creating a directory for every variant of murmur,
  just putting each variant in a separate .c file.  Eg:
  
  src/common/lib/libc/hash/murmurhash/murmurhash2.c
  src/common/lib/libc/hash/murmurhash/murmurhash3.c
  
  Or do you intend on adding other variants of murmur to the current .c
  file if/when needed?
 
 Yes, I would like to add MurmurHash3 to the same module.  Having them in
 the same module enables easier code reuse, when it's the case.  Do you
 see a good reason to have them in separate modules?

There's practically no code to reuse between the two hashes.  It's also
worth noting that the reference implementation keeps the code for the
two (three including the original murmurhash1) in separate source files.

Cheers,
Simon.


Re: CVS commit: src

2011-12-20 Thread Simon Burge
Joerg Sonnenberger wrote:

 On which mailling list was this change discussed?

One thing that jumps out: Should this new code panic in sys_mmap() if it
can't handle a request instead of just failing the request?  That seems
a little ... heavy handed.

Please also stick to KNF (#defineTAB), especially when you add
something to the middle of an existing block of #defines (eg
sys/proc.h).

Cheers,
Simon.

 
 On Tue, Dec 20, 2011 at 03:39:36PM +, Reinoud Zandijk wrote:
  Module Name:src
  Committed By:   reinoud
  Date:   Tue Dec 20 15:39:36 UTC 2011
  
  Modified Files:
  src/lib/libc/sys: mmap.2
  src/sys/sys: mman.h proc.h
  src/sys/uvm: uvm_extern.h uvm_map.c uvm_mmap.c
  
  Log Message:
  Add a MAP_NOSYSCALLS flag to mmap. This flag prohibits executing of system
  calls from the mapped region. This can be used for emulation perposed or for
  extra security in the case of generated code.
  
  Its implemented by adding mapping-attributes to each uvm_map_entry. These 
  can
  then be queried when needed.
  
  Currently the MAP_NOSYSCALLS is only implemented for x86 but other
  architectures are easy to adapt; see the sys/arch/x86/x86/syscall.c patch.
  Port maintainers are encouraged to add them for their processor ports too.
  When this feature is not yet implemented for an architecture the
  MAP_NOSYSCALLS is simply ignored with virtually no cpu cost..
  
  
  To generate a diff of this commit:
  cvs rdiff -u -r1.44 -r1.45 src/lib/libc/sys/mmap.2
  cvs rdiff -u -r1.42 -r1.43 src/sys/sys/mman.h
  cvs rdiff -u -r1.311 -r1.312 src/sys/sys/proc.h
  cvs rdiff -u -r1.176 -r1.177 src/sys/uvm/uvm_extern.h
  cvs rdiff -u -r1.307 -r1.308 src/sys/uvm/uvm_map.c
  cvs rdiff -u -r1.139 -r1.140 src/sys/uvm/uvm_mmap.c
  
  Please note that diffs are not public domain; they are subject to the
  copyright notices on the relevant files.
  
 


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

2011-12-12 Thread Simon Burge
KIYOHARA Takashi wrote:

 Module Name:  src
 Committed By: kiyohara
 Date: Mon Dec 12 11:23:58 UTC 2011
 
 Modified Files:
 
   src/sys/arch/evbppc/explora: autoconf.c
   src/sys/arch/evbppc/obs405: obs200_autoconf.c obs266_autoconf.c
   obs600_autoconf.c
   src/sys/arch/evbppc/virtex: autoconf.c
   src/sys/arch/evbppc/walnut: autoconf.c
 
 Log Message:
 
 Fix hangs-up.  Remove wrteei 1 in board's cpu_configure().  Interrupt
 is enabled in powerpc-layer.

This code is pretty much unchanged for over a decade.  Did the interrupt
enable code in the powerpc layer change recently?  I'm curious about
how/why this broke.

Cheers,
Simon.


Re: CVS commit: src/external/bsd/libevent/dist

2011-09-18 Thread Simon Burge
Joerg Sonnenberger wrote:

 Which 15 changes in src/external are you talking about?

Some of them were only Makefile changes, so trimmed from the list;

src/crypto/external/bsd/openssh
  Message-Id: 20110825153701.1ff6b17...@cvs.netbsd.org
  Message-Id: 20110829210854.ee03417...@cvs.netbsd.org
  Message-Id: 20110916153601.9b20817...@cvs.netbsd.org
  Message-Id: 20110916153618.7009617...@cvs.netbsd.org
src/external/bsd/file (after I sent my previous email)
  Message-Id: 20110917104653.247c917...@cvs.netbsd.org
src/external/bsd/flex
  Message-Id: 20110827183603.d4dcd17...@cvs.netbsd.org
src/external/bsd/libarchive
  Message-Id: 20110916162736.e81bf17...@cvs.netbsd.org
src/external/bsd/libevent
  Message-Id: 20110916160903.c409c17...@cvs.netbsd.org
src/external/bsd/libpcap
  Message-Id: 20110916160925.83e7d17...@cvs.netbsd.org
src/external/bsd/tmux
  Message-Id: 20110825164151.6308017...@cvs.netbsd.org
src/external/historical/nawk
  Message-Id: 20110916160947.6659f17...@cvs.netbsd.org

 Most of them are
 either to pieces already heavily modified (OpenSSH),

Does that stop feeding changes back?

 very rarely updated
 (libpcap)

Does that stop feeding changes back?

 or where it is hard to impossible to get any chances included
 (nawk, byacc).

Why is that?

 In this case I am going to talk with upstream.

In light of your previous message, it wasn't obvious if you were also
doing that.

Cheers,
Simon.


Re: CVS commit: src/external/bsd/libevent/dist

2011-09-16 Thread Simon Burge
Joerg Sonnenberger wrote:

 Module Name:  src
 Committed By: joerg
 Date: Fri Sep 16 16:09:03 UTC 2011
 
 Modified Files:
 
   src/external/bsd/libevent/dist: log.h
 
 Log Message:
 
 Use __dead

Has this and the other 15 or so changes you've made to src/external in
the last month all been feed back to the relative maintainers?

 From: Joerg Sonnenberger jo...@britannica.bec.de
 To: source-chan...@netbsd.org
 Cc: source-changes-d@NetBSD.org
 Subject: Re: CVS commit: src/external/bsd/mdocml
 Date: Wed, 17 Aug 2011 23:28:05 +0200
 
 Could you please stop randomly changing 3rd party code without
 contacting the maintainer?
 
 Joerg

Cheers,
Simon.


Re: CVS commit: src/share/man/man4

2011-08-30 Thread Simon Burge
Martin Husemann wrote:

 Just curious: are there analog TV feeds out there, anywhere, still?

Some parts of Australia until the end of next year...

Cheers,
Simon.


Re: CVS commit: src/sys/arch

2011-06-09 Thread Simon Burge
Matt Thomas wrote:

 Module Name:  src
 Committed By: matt
 Date: Tue Jun  7 00:48:32 UTC 2011
 
 Modified Files:
 
   [ ... alpha files ... ]
   src/sys/arch/mips/mips: mips_machdep.c
   src/sys/arch/powerpc/powerpc: fpu.c powerpc_machdep.c
 
 Log Message:
 
 Switch alpha to use PCU to manage the FPU.
 Tested by mhitch and review by rmind.

Where the MIPS and PowerPC changes in this commit deliberate?

Cheers,
Simon.


Re: CVS commit: src/sys/kern

2011-06-03 Thread Simon Burge
Martin Husemann wrote:

 On Thu, Jun 02, 2011 at 09:21:11PM +0100, David Laight wrote:
  Passing 'l' is a register rename (or copy) so is almost zero cost.
  
  Recovering curlwp may involve a function call, and is, at best, a real
  memory access of global data (possibly via an asm statement) that will
  be slow and multiple accesses might need caching in a local anyway.
 
 I wonder on what archs we would be able to do the MIPS curlwp optimization
 (place curlwp in a reserved register).
 
 Sparc64 and sparc will likely follow this in the near future (needs some audit
 and will do some benchmarks first; it closely resembles TLS for userland).
 
 What's the cost on other archs and what optimizations are possible?

As far as I could tell, the change to put curlwp in a register was never
actually benchmarked on MIPS.  I asked a few times and never got an
answer, other than that a kernel was about 2.5kB smaller.

I'd be rather curious that if other arches investigate this, especially
if there's some performance data to back up the change this time around.

Cheers,
Simon.


Re: CVS commit: src

2011-01-30 Thread Simon Burge
Matt Thomas wrote:

 On Jan 28, 2011, at 3:38 PM, matthew green wrote:
 
  
  disklabel.h should export nothing to userland and values userland
  needs should be obtained via sysctl.
  
  I've been asking this question of various developers for a while.
  
  how do i create a disklabel on a file system image as a normal
  user a non-netbsd host with this method?
 
 But that would be a hosted tool and that's a different case than 
 a native tool.  

Where would the hosted tool get that information from?  If it's from a
MD header file we're back to where we started...

Cheers,
Simon.


Re: CVS commit: src

2011-01-28 Thread Simon Burge
Antti Kantee wrote:

 On Fri Jan 28 2011 at 18:05:50 +0900, Izumi Tsutsui wrote:
   Out of curiosity, was there any thought is adding this to evbmips
   instead of getting its own top-level arch subdir?
  
  emips already has native bootloader and src/distrib files,
  so it's enough reason to have own port dir.

Fair enough here, this isn't something that evb* handles well.  One day
I'd like to move sbmips under evbmips but sbmips/stand is the biggest
part of work there.

 additionally, userland is built with MKSOFTFLOAT=yes

Was softfloat vs kernel emulation ever benchmarked?  It's been many
years since I looked at this but my (very vague) recollection was that
there was no real difference and there are then the benefits of sharing
binaries with other MIPS ports.

 plus, what was said about a research platform,
 with implications for teaching too.

This is the only point you raise that I don't understand.  How does its
location in the source tree effect its use as a research platform?

Cheers,
Simon.


Re: CVS commit: src

2011-01-27 Thread Simon Burge
Hi Pooka,

Antti Kantee wrote:

 Module Name:  src
 Committed By: pooka
 Date: Wed Jan 26 01:18:55 UTC 2011
 
 Added Files:
 
   [ ... ]
   src/sys/arch/emips: Makefile

Out of curiosity, was there any thought is adding this to evbmips
instead of getting its own top-level arch subdir?  My understanding is
that its implementation is in FPGA only and in that respect is similar
to the PowerPC Virtex that lives in arch/evbppc/virtex.

Cheers,
Simon.


Re: CVS commit: src

2011-01-17 Thread Simon Burge
Jukka Ruohonen wrote:

 Module Name:  src
 Committed By: jruoho
 Date: Mon Jan 17 11:09:08 UTC 2011
 
 Modified Files:
 
   src/distrib/sets/lists/comp: mi
   src/share/misc: Makefile
 Removed Files:
 
   src/share/misc: operator
 
 Log Message:
 
 Remove /usr/share/misc/operator.

Why was this removed when there was an active discussion about removing
it where no concensus was reached?  This sort of thing where commis
occur before a discussion is finished seems to be occurring more and
more often.

Cheers,
Simon.


Re: CVS commit: src/sys/arch/pmax/stand/common

2010-11-25 Thread Simon Burge
Matt Thomas wrote:

 On Nov 25, 2010, at 9:00 AM, Antti Kantee wrote:
 
  On Fri Nov 26 2010 at 01:50:11 +0900, Izumi Tsutsui wrote:
  but shouldn't we fix stub first, then discuss pros and blah of the change?
  Current binaries have not worked at all on MIPS1 since the last December.
  
  Like I said, I don't have strong feelings about this.
  
  If you want to fix stubs, go for it!
  (there's no need for a discussion after that, anyway, since the issue
  is decided and fixed)
 
 Please don't.  I've changed the mips1 syscall handler to save t0-t2
 just like the mips3+ handler does.

Why is it necessary to save three extra regs for every syscall, when
only two syscalls actually use t0?  Callers of the syscalls don't expect
t0-t3 to be saved.

Also, why go to the effort of saving t0-t2 and not t3 as well?  Surely
that violates POLA?

Cheers,
Simon.


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

2010-11-09 Thread Simon Burge
Antti Kantee wrote:

 On Tue Nov 09 2010 at 13:10:02 +1100, Simon Burge wrote:
  David Holland wrote:
  
   On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
 Modified Files:
src/sys/arch/mips/mips: locore_mips1.S
 
 Log Message:
 In TLBRead, restore PID before doing the saves so that the caller's
 TLB entries are used instead of the PID given as the argument.
 
 from Alessandro Forin
   
   [ ... ]
   
   Do you have any further explanations or reports of symptoms? I don't
   see anything on any of the mips lists.
  
  I'm curious about this too.  That code hasn't changed for at least
  14 years...
 
 Given that it's only called from ddb, i'm not too surprised nobody has
 noticed.  Now, unless someone argues that the stores should definitely
 happen with the arbitrary PID set up by tlbr, let's flag the change as
 obvious, get on with something useful, and leave noppy philosophy to
 some other book club.

Thanks for the extra details.  It may be obvious with the background
info you've now provided, but wasn't from your initial commit message.

Cheers,
Simon.


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

2010-11-08 Thread Simon Burge
David Holland wrote:

 On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
   Modified Files:
  src/sys/arch/mips/mips: locore_mips1.S
   
   Log Message:
   In TLBRead, restore PID before doing the saves so that the caller's
   TLB entries are used instead of the PID given as the argument.
   
   from Alessandro Forin
 
 [ ... ]
 
 Do you have any further explanations or reports of symptoms? I don't
 see anything on any of the mips lists.

I'm curious about this too.  That code hasn't changed for at least
14 years...

Cheers,
Simon.


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

2010-11-06 Thread Simon Burge
Masao Uebayashi wrote:

 Module Name:  src
 Committed By: uebayasi
 Date: Sat Nov  6 16:36:27 UTC 2010
 
 Modified Files:
 
   src/sys/arch/powerpc/ibm4xx: pmap.c
   src/sys/arch/powerpc/include/ibm4xx: vmparam.h
 
 Log Message:
 
 Merge from uebayasi-xip:
 
 revision 1.60.2.5
 date: 2010/08/14 02:09:57;  author: uebayasi;  state: Exp;  lines: +2 -1
 Teach TLB miss handler (pmap_tlbmiss()) to map Expansion ROM area as
 PA == VA.  Now we don't need to reserve a TLB entry for it.
 

At a quick glance, this seems to hard-wire in device addresses which may
not be the same on every ibm4xx platform (the 0xef00 address).

Also I'm not sure I like the idea of modifying a general pmap to have
knowledge of device-specific Expansion ROM address ranges.  Are these
_always_ guaranteed to live in the address range you've specified or
is there a chance a ROM could be mapped at different addresses on some
boards?  The change as is also limits expansion ROMs to a bit over
256MB which mightn't be a problem now but also indicates a problem with
hardcoding specific values in a general pmap.

I'm not sure what the correct way of doing this is.  I think I'd
prefer to see some sort of registration of expansion ROM space that you
want to reserve, but would need to put some more thought in to it.

If this change was to remain in its current form, the comment
immediately above the change you made in the tlb miss handler is now
incorrect and would need to be adjusted.

Cheers,
Simon.


Re: CVS commit: src/sys/ddb

2010-08-31 Thread Simon Burge
Thor Lancelot Simon wrote:

 Module Name:  src
 Committed By: tls
 Date: Mon Aug 30 19:23:26 UTC 2010
 
 Modified Files:
 
   src/sys/ddb: db_input.c

Was there any particular reason for removing the lint directives in this
change?  Eg:

-   } while (/*CONSTCOND*/ 0)
+} while (0)

Cheers,
Simon.


Re: CVS commit: src/doc

2010-08-25 Thread Simon Burge
Izumi Tsutsui wrote:

  Mention mips64 support (from the first branch merge) by matt@,
  so details wont be forgotten in the release notes.
 
 IMO, no one will forget it because all mips ports have been broken
 since the merge and we won't get the next release unless it's fixed.
 
 Anyway, if you would like to mention it, we should also mention
 it's broken in the HEAD.

Are there any specific problems or (even better) PRs for this
brokenness?  I've fixed all the lossage the mips64 merge has caused
that I'm aware of, but admit that I haven't had time to track all
the issues.

Cheers,
Simon.


Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/mips

2010-06-11 Thread Simon Burge
Hi Cliff,

A couple of things with these changes:

 Module Name:src
 Committed By:   cliff
 Date:   Thu Jun 10 00:32:11 UTC 2010
 
 Modified Files:
 
 src/sys/arch/mips/include [matt-nb5-mips64]: locore.h
 
 Log Message:
 
 - add lsw_bus_error to struct locoresw, provides hook to call
 for chip-specific bus error handling/decode from e.g. trap()

and

 Module Name:  src
 Committed By: cliff
 Date: Thu Jun 10 00:33:51 UTC 2010
 
 Modified Files:
 
   src/sys/arch/mips/mips [matt-nb5-mips64]: trap.c
 
 Log Message:
 
 - in trap(), if traptype is bus error, call chip-specific bus error
 handler in locoresw: (*mips_locoresw.lsw_bus_error)(cause)

1: It's not obvious to me if you're trying to provide for a replacement
bus error handler (as the commit seems to imply) or an assistant to
the current bus error handler (which is what the code does).

2: With:

if ((TRAPTYPE(cause) == 6) || (TRAPTYPE(cause) == 7))
(void)(*mips_locoresw.lsw_bus_error)(cause);

please please avoid magic numbers - the intent of this isn't obvious at
all.

3: It appears that only sbmips actually sets the lsw_bus_error handler,
so a bus error on any other arch would NULL-deference and panic?

4: With:

#ifdef MIPS3_PLUS
#define TRAPTYPE(x) (((x)  MIPS3_CR_EXC_CODE)  MIPS_CR_EXC_CODE_SHIFT)
#else
#define TRAPTYPE(x) (((x)  MIPS1_CR_EXC_CODE)  MIPS_CR_EXC_CODE_SHIFT)
#endif

This looks like it assumes MIPS1 or MIPS3+ at compile time, but we can
have one kernel that can run on both.  This needs to be a runtime thing.
Maybe create a macro/inline function to extract the EXC part of a cause
reg in mips/include/cpureg.h too?

5: Is this worth generalising?  Someone might want to add other CPU
specific trap error handlers so it might be better doing something like:

if (mips_locoresw.lsw_trap_error)
(void)(*mips_locoresw.lsw_trap_error)(status, cause, vaddr, 
opc);

and letting the handler determine which exception codes to deal with.
This isn't in time critical code (it either panics or drops to ddb/kgdb)
to the if () check doesn't hurt.  This would also fix 3 above.

Cheers,
Simon.


Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include

2010-05-12 Thread Simon Burge
Matt Thomas wrote:

 Module Name:  src
 Committed By: matt
 Date: Tue May 11 21:51:34 UTC 2010
 
 Modified Files:
 
   src/sys/arch/mips/include [matt-nb5-mips64]: locore.h
 
 Log Message:
 
 Need to turn KX for N32 kernels with mips3_lw_a64 and mips3_sw_a64

+#elif defined(__mips_n32)
+   uint32_t sr = mips_cp0_status_read();
+   mips_cp0_status_write((sr  ~MIPS_SR_INT_IE) | MIPS3_SR_KX);
+   rv = *(const uint32_t *)addr;

Erm, doesn't that cast toss away the high 32-bits of the address
you're try to load/store from/to?

Cheers,
Simon.


Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include

2010-05-12 Thread Simon Burge
Matt Thomas wrote:

 Module Name:  src
 Committed By: matt
 Date: Tue May 11 22:08:02 UTC 2010
 
 Modified Files:
 
   src/sys/arch/mips/include [matt-nb5-mips64]: locore.h
 
 Log Message:
 
 Use assembly since deref a 64bit value as a pointer does not make a
 32bit compiler happy.

Dang, ignore my previous because this code is a little different.

+   __asm volatile(lw  %0, 0(%1) : =r(rv) : d(addr));

d is listed as General-purpose integer register in the gcc docs.
Does the new code pass the full 64-bits of addr in when compiled on an
ABI where an int is 32-bits even though a full register is 64-bits?

Cheers,
Simon.


Re: CVS commit: src/sys

2010-03-13 Thread Simon Burge
Darran Hunt wrote:

 Added Files:
   src/sys/sys: kern_ctf.h

The convention for include files in sys/sys doesn't include a kern_
prefix in the name - would it make sense to add this as sys/ctf.h
instead?

Cheers,
Simon.


Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips

2010-02-05 Thread Simon Burge
Matt Thomas wrote:

 Module Name:  src
 Committed By: matt
 Date: Fri Feb  5 07:36:51 UTC 2010
 
  [ ... ]
 
 Add __HAVE_FAST_SOFTINTS support.
 Add routine to remap an uarea via a direct-mapped address.  This avoids
 TLB machinations when swtching to/from the softint thread.  This can only
 be done for lwp which won't exit.


Is this printf in cpu_uarea_remap() meant to be there?

+   printf(ctx=%#PRIxVADDR utf=%p\n, 
+   (vaddr_t)l-l_addr-u_pcb.pcb_context.val[_L_SP],
+   l-l_md.md_utf

Cheers,
Simon.


CVS commit: src/usr.bin/calendar/calendars

2010-01-20 Thread Simon Burge
Module Name:src
Committed By:   simonb
Date:   Thu Jan 21 01:59:09 UTC 2010

Modified Files:
src/usr.bin/calendar/calendars: calendar.birthday

Log Message:
Use TAB as a separator to be consistent with the rest of this file.


To generate a diff of this commit:
cvs rdiff -u -r1.20 -r1.21 src/usr.bin/calendar/calendars/calendar.birthday

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/sys/arch/mips/mips

2010-01-09 Thread Simon Burge
Module Name:src
Committed By:   simonb
Date:   Sat Jan  9 11:49:17 UTC 2010

Modified Files:
src/sys/arch/mips/mips: lock_stubs.S

Log Message:
Don't always use .set mips3 - that explicitly uses 64-bit instructions
and we may be on a 32-bit CPU.  Instead use .set mips3/mips32/mips64
depending on current build arch.

Should fix boot problems on a Alchemy CPU reported by KIYOHARA Takashi
on port-mips.

A couple of niggles/concerns:
 * XXX Clean up with a macro?  Same code fragment is in mipsX_subr.S too.
 * XXX Key off build abi instead of processor type?


To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.11 src/sys/arch/mips/mips/lock_stubs.S

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



Re: CVS commit: src/gnu

2009-11-13 Thread Simon Burge
Izumi Tsutsui wrote:

  On Fri, Nov 13, 2009 at 06:46:07PM +0900, Izumi Tsutsui wrote:
   Indeed, it doesn't use libbfd but just GPLv2'ed.
   As you said we should move only mdsetimage and dbsym into external/gpl3.
  
  Do we need that for any non-elf targets?
  If not, porting to FreeBSD's libelf might be an option.
 
 It looks authors chose GPLv2 regardless of ELF support.
 (though we might be able to ask to change their license)

mdsetimage started off as BSD licenced, and I convinced the author to
allow to be dual licenced (or changed to GPL2 - I don't recall) so that
it could use libbfd and then used as a cross-build tool.  I then wrote a
new dbsym based on mdsetimage.

If they were converted to use libelf, mdsetimage is already clear to
use a BSD licence and if dbsym isn't BSD licenced I obviously have no
problem re-licencing it :-)

Cheers,
Simon.


Re: CVS commit: [matt-nb5-mips64] src/sys/conf

2009-09-05 Thread Simon Burge
matthew green wrote:

 I see no reason to make it fatal.

Otherwise we cannot detect errors on release build,
i.e. no ksym(4) supports.

 It means that when I build a kernel  
 with
 DEBUG, my kernel build will fail.  That's stupid.

Then disable it only if DEBUG, or keep it only in your local tree.
 
 
 why can't we make it size for DEBUG builds and not fail anywhere?

The proper fix would be to dynamically size this somehow, so that no
space is ever wasted.

Cheers,
Simon.


Re: CVS commit: src/sys/arch/evbmips/gdium

2009-08-19 Thread Simon Burge
Matt Thomas wrote:

 Module Name:  src
 Committed By: matt
 Date: Mon Aug 17 18:57:34 UTC 2009
 
 Modified Files:
 
   src/sys/arch/evbmips/gdium: machdep.c
 
 Log Message:
 
 Use mips3_sd instead of two 32bit stores.

Any reason for this?  The two reg stores will be faster because of no
function call.

The main (only?) user of mips3_{sd,ld} was the bcm1xxx CPUs which had
some device regs that didn't work with 32-bit load/store and needed a
64-bit load/store.

Cheers,
Simon.


Re: CVS commit: src/sys/arch/mips/conf

2009-08-01 Thread Simon Burge
Matt Thomas wrote:

 Add MIPS64_LOONGSON2F since it needs some special help in various places.

Isn't the Loongson (barely) a MIPS3 and not a MIPS64?

Cheers,
Simon.


PCI domains [Was: CVS commit: xsrc/external/mit/libpciaccess/dist/src]

2009-07-09 Thread Simon Burge
Christoph Egger wrote:

 Michael Lorenz wrote:

  +/*
  + * NetBSD's userland has a /dev/pci* entry for each bus but userland has 
  no way
  + * to tell if a bus is a subordinate of another one or if it's on a 
  different
  + * host bridge.
 
 I have a patch which introduces support for PCI domains. It allows the
 userland to distinguish between them by checking if the pci bus belongs
 to the same PCI domain.

What exactly is a PCI domain?  A quick google seems to suggest that
this is a Linux concept as opposed to a PCI concept.  In a previous
life we used NetBSD on a number of different machines of various
architectures that had multiple PCI host bridges, although admittedly we
didn't need to know the topology of the PCI bus layout.

Cheers,
Simon.


Re: CVS commit: othersrc/zfs/external/cddl/osnet/dist

2009-03-26 Thread Simon Burge
Andrew Doran wrote:

 Module Name:  othersrc
 Committed By: ad
 Date: Thu Mar 26 21:50:47 UTC 2009
 
 Modified Files:
 
   othersrc/zfs/external/cddl/osnet/dist/cmd/zpool: zpool_vdev.c
   othersrc/zfs/external/cddl/osnet/dist/cmd/ztest: ztest.c
   othersrc/zfs/external/cddl/osnet/dist/uts/common/fs/zfs: arc.c dmu.c
   dsl_deleg.c spa.c spa_history.c vdev_disk.c zfs_ctldir.c zfs_dir.c
   zfs_ioctl.c zfs_vfsops.c zfs_znode.c zvol.c
   othersrc/zfs/external/cddl/osnet/dist/uts/common/fs/zfs/sys:
   vdev_disk.h zfs_znode.h zvol.h
 
 Log Message:
 
 Apply NetBSD changes.

Just out of interest...


Index: othersrc/zfs/external/cddl/osnet/dist/uts/common/fs/zfs/arc.c
diff -u othersrc/zfs/external/cddl/osnet/dist/uts/common/fs/zfs/arc.c:1.1.1.1 
othersrc/zfs/external/cddl/osnet/dist/uts/common/fs/zfs/arc.c:1.2
--- othersrc/zfs/external/cddl/osnet/dist/uts/common/fs/zfs/arc.c:1.1.1.1   
Fri Mar 27 08:43:43 2009
+++ othersrc/zfs/external/cddl/osnet/dist/uts/common/fs/zfs/arc.c   Fri Mar 
27 08:50:47 2009
@@ -133,6 +133,42 @@
 #include sys/callb.h
 #include sys/kstat.h
   
+#ifdef __NetBSD__
+#include uvm/uvm.h
+#definebtop(x) ((x) * PAGE_SIZE)
  [ ... ]

Isn't that working out pages to bytes and not bytes to pages ?

Unless btop() means something non-obvious in Solaris land...

Simon.