re: CVS commit: src/sys/arch/aarch64/aarch64

2021-01-17 Thread matthew green
> Log Message:
> Fix build as crash(8); Protect db_md_meminfo_cmd() by defined(_KERNEL).

thanks.  surprised i never saw this as the change was in a
tree for a few weeks, but i guess i was mostly doing kernels
in that tree not full builds..


.mrg.


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

2021-01-17 Thread Rin Okuyama

On 2021/01/18 14:49, Rin Okuyama wrote:

(2) However, in clock.c rev 1.31 and prior, curcpu->ci_idepth was not
     raised before calling {hard,stat}clock(). Therefore, cpu_intr_p()
     wrongly returns false. As a result, callee functions misunderstood
     that they are not running in the interrupt context.


1.31 --> 1.30

Sorry for bothering you many times...

rin


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

2021-01-17 Thread Rin Okuyama

On 2021/01/18 13:35, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Mon Jan 18 04:35:05 UTC 2021

Modified Files:
src/sys/arch/powerpc/ibm4xx: clock.c

Log Message:
Invoke hardclock() and statclock() in the interrupt context.

Otherwise, entropy_enter() is used instead of entropy_enter_intr() in
statclock(), which results in KASSERT() failure.


To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/arch/powerpc/ibm4xx/clock.c


This message is somewhat misleading. I meant:

(1) Callers are interrupt handlers, therefore, {hard,stat}clock() are
apparently invoked in the interrupt context.

(2) However, in clock.c rev 1.31 and prior, curcpu->ci_idepth was not
raised before calling {hard,stat}clock(). Therefore, cpu_intr_p()
wrongly returns false. As a result, callee functions misunderstood
that they are not running in the interrupt context.

I have to improve my English writing skills ;-).

Thanks,
rin


Re: CVS commit: src/sys/compat/netbsd32

2021-01-17 Thread Roy Marples

Hi Simon

On 17/01/2021 11:26, Simon Burge wrote:

On 15/01/2021 07:15, matthew green wrote:

Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
and is the same struct on all BSD. While bringing the same functionality to
IPv4, I elected to keep the same struct just to have the same API, warts
and all. I like consistency.


Does anyone else have an in_nbrinfo?  I _think_ the "asked" member only
seems to get assigned a 0 for ipv4, and with a long being 32-bits on any
32 bit platform making it a long instead of an int doesn't buy anything.


No, it's currently unique to NetBSD.
Other BSD's just don't have the infrastructure in their network for it either.
I'll note that on a 64-bit platform it's 64 bits though so these do gains 
something.

The value is similar to struct if_data counters really, so maybe it should be a 
uint64_t if you really want to change it.
I would then argue that it might be better then to version it proper and move it 
out of compat32.




I'm still keen to make this change (asked as an int instead of a long in
in_nbrinfo) and announce a mini flag day for arp for -current users so
that it's one less compat32 ioctl we have to maintain.


I would just like arp to work without error.
My personal preference would be to keep the same API and add compat.


I've committed compat32 support for SIOCGNBRINFO_IN6 and in6_nbrinfo.


Looks great!
Also looks the same as what I did but couldn't get to work.
Maybe I missed the netbsd32 on the long.

Roy


Re: CVS commit: src/sys/dev/wscons

2021-01-17 Thread Jared McNeill
The change isn't wrong, but I booted the wrong kernel and it does not fix 
the aarch64 issue I am seeing.


On Sun, 17 Jan 2021, Jared D. McNeill wrote:


Module Name:src
Committed By:   jmcneill
Date:   Sun Jan 17 15:13:15 UTC 2021

Modified Files:
src/sys/dev/wscons: wsdisplay_vconsvar.h

Log Message:
Add appropriate memory barriers around sc_busy accesses. Fixes an issue
where character cells are sometimes not erased properly on aarch64 at
boot.


To generate a diff of this commit:
cvs rdiff -u -r1.28 -r1.29 src/sys/dev/wscons/wsdisplay_vconsvar.h

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




Re: CVS commit: src/sys/compat/netbsd32

2021-01-17 Thread Simon Burge
Hi Roy,

Roy Marples wrote:

> On 15/01/2021 07:15, matthew green wrote:
> >> Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
> >> and is the same struct on all BSD. While bringing the same functionality to
> >> IPv4, I elected to keep the same struct just to have the same API, warts
> >> and all. I like consistency.

Does anyone else have an in_nbrinfo?  I _think_ the "asked" member only
seems to get assigned a 0 for ipv4, and with a long being 32-bits on any
32 bit platform making it a long instead of an int doesn't buy anything.

I'm still keen to make this change (asked as an int instead of a long in
in_nbrinfo) and announce a mini flag day for arp for -current users so
that it's one less compat32 ioctl we have to maintain.

> > [ .. ]
> >> 
> >> That breaks API/ABI though yes? As such it would require stuff in compat
> >> anyway, but leaving it as it just needs n32 compat gunk instead which is
> >> less impactful on other systems.
> > 
> > in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can
> > choose to break them in -current.  there's a slight problem that -current 
> > has
> > a minor flag day here, but it's not the compat issue you seem to think.
>
> CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2=text/x-cvsweb-markup_with_tag=netbsd-1-5

Sorry, I only checked the history of in_nbrinfo and just assumed that
in6_nbrinfo was of a similar vintage.  I've committed compat32 support
for SIOCGNBRINFO_IN6 and in6_nbrinfo.

Cheers,
Simon.


re: CVS commit: src/share/man/man5

2021-01-15 Thread matthew green
> Note that `entropy' is not an `rcvar' the way upsdriver is (if your

ah!  i missed this, and wasn't really even thinking about
more than foo and foo_flags.  thanks!


.mrg.


re: CVS commit: src/sys/dev/acpi

2021-01-15 Thread matthew green
"Jason R Thorpe" writes:
> Module Name:  src
> Committed By: thorpej
> Date: Sat Jan 16 01:23:04 UTC 2021
>
> Modified Files:
>   src/sys/dev/acpi: tpm_acpi.c
>
> Log Message:
> Match PNP0C31 as a TPM 1.2 device.  Works on my ThinkPad X260, and
> eliminates the last of the devices that attach to "isa".

cool.

now try to remove all the "at isa" devices in your config :-)

(it explodes last i tried.)


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

2021-01-15 Thread Valery Ushakov
On Sat, Jan 16, 2021 at 14:46:46 +1100, matthew green wrote:

> > Log Message:
> > Tweak wording for consistency: `if empty or not set', not `if unset'.
> 
> is this correct?
> 
> rc complains if unset or not set (ie, if "$foo" is zero length):
> 
> /etc/rc.d/upsdriver: WARNING: $upsdriver is not set properly - see rc.conf(5).

What Taylor said.  The above warning reflects the status of
checkyesnox() that checks that the value is yes/true/1 or no/false/0.

-uwe


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

2021-01-15 Thread Taylor R Campbell
> Date: Sat, 16 Jan 2021 14:46:46 +1100
> from: matthew green 
> 
> > Log Message:
> > Tweak wording for consistency: `if empty or not set', not `if unset'.
> 
> is this correct?
> 
> rc complains if unset or not set (ie, if "$foo" is zero length):
> 
> /etc/rc.d/upsdriver: WARNING: $upsdriver is not set properly - see rc.conf(5).

The allowed settings are:

entropy=check
entropy=wait
entropy=""

Note that `entropy' is not an `rcvar' the way upsdriver is (if your
/etc/rc.d/upsdriver is pkgsrc/sysutils/ups-nut/files/upsdriver.sh).
Compare, e.g., `domainname' or `hostname' in rc.conf(5).


re: CVS commit: src/share/man/man5

2021-01-15 Thread matthew green
> Log Message:
> Tweak wording for consistency: `if empty or not set', not `if unset'.

is this correct?

rc complains if unset or not set (ie, if "$foo" is zero length):

/etc/rc.d/upsdriver: WARNING: $upsdriver is not set properly - see rc.conf(5).


.mrg.


Re: CVS commit: src/sys/compat/netbsd32

2021-01-15 Thread Roy Marples

On 15/01/2021 02:43, Simon Burge wrote:

I'll test a bit more

I can't actually test as my ERLite won't boot anymore.
Console light is green, cu says I'm connected but I get nothing out of it.
With cat5 cables plugged in the ports they flash green and then stick on amber.

I'm guessing this is non recoverable :(
If it is recoverable somehow I can put NetBSD back on it as I have a shiny new 
USG in it's place.


Roy


Re: CVS commit: src/sys/compat/netbsd32

2021-01-14 Thread Roy Marples

On 15/01/2021 07:15, matthew green wrote:

Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
and is the same struct on all BSD. While bringing the same functionality to
IPv4, I elected to keep the same struct just to have the same API, warts
and all. I like consistency.

[ .. ]


That breaks API/ABI though yes? As such it would require stuff in compat
anyway, but leaving it as it just needs n32 compat gunk instead which is
less impactful on other systems.


in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can
choose to break them in -current.  there's a slight problem that -current has
a minor flag day here, but it's not the compat issue you seem to think.


CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2=text/x-cvsweb-markup_with_tag=netbsd-1-5

Roy


re: CVS commit: src/sys/compat/netbsd32

2021-01-14 Thread matthew green
> Oh, I quite agree.
> However, in6_nbrinfo predates my involvement with NetBSD and is the same 
> struct 
> on all BSD. While bringing the same functionality to IPv4, I elected to keep 
> the 
> same struct just to have the same API, warts and all. I like consistency.
[ .. ]
>
> That breaks API/ABI though yes?
> As such it would require stuff in compat anyway, but leaving it as it just 
> needs 
> n32 compat gunk instead which is less impactful on other systems.

in6_nbrinfo/in_nbrinfo are not in any published netbsd release
so we can choose to break them in -current.  there's a slight
problem that -current has a minor flag day here, but it's not
the compat issue you seem to think.

with simon's proposed patch, the API doesn't change, so there
no source compat issue to worry about either.  this _only_
breaks -current in the last 4 months or so.


i think we should do this, rather than add additional compat.
we're allowed (and should!) fix -current issues like this.


.mrg.


Re: CVS commit: src/sys/compat/netbsd32

2021-01-14 Thread Roy Marples

On 15/01/2021 02:43, Simon Burge wrote:

Hi Roy,

Roy Marples wrote:


On 14/01/2021 11:03, Simon Burge wrote:

Sure, I will have a look.  Anything IPv6 related I might need a helping
hand to get a test case though :).


As they share a similar structure, you solve one you likely solve the other.
I can assume you have working IPv4 ;)


In general where we can define the structure that are passed in an
interface, regardless if it's a ioctl or sysctl or whatever, we should
try to design the structure so that it's the same regardless of if it's
built with 32-bit or 64-bit userlands.


Oh, I quite agree.
However, in6_nbrinfo predates my involvement with NetBSD and is the same struct 
on all BSD. While bringing the same functionality to IPv4, I elected to keep the 
same struct just to have the same API, warts and all. I like consistency.




The issue with in_nbrinfo and in6_nbrinfo is that there's a "long" in
the structure, so this has different sizes depending on your native long
size.

I _think_ this is the is value out of the la_asked member of struct
llentry which is a uint16_t so we can just make it an int the your
structures will align nicely.  In both cases the ifname name is 16
bytes.  For in_nbrinfo in_addr is effectively an int so we have just
four ints after the ifname.  For in6_nbrinfo the in6_addr is 128 bytes
so aligns nicely, then a couple more ints after that.

If "asked" is from struct llentry then the attached patch should work
without requiring any compat32 support.  If you're happy with this, I'll
test a bit more then commit.


That breaks API/ABI though yes?
As such it would require stuff in compat anyway, but leaving it as it just needs 
n32 compat gunk instead which is less impactful on other systems.


Roy


Re: CVS commit: src/sys/compat/netbsd32

2021-01-14 Thread Simon Burge
Hi Roy,

Roy Marples wrote:

> On 14/01/2021 11:03, Simon Burge wrote:
> > Sure, I will have a look.  Anything IPv6 related I might need a helping
> > hand to get a test case though :).
>
> As they share a similar structure, you solve one you likely solve the other.
> I can assume you have working IPv4 ;)

In general where we can define the structure that are passed in an
interface, regardless if it's a ioctl or sysctl or whatever, we should
try to design the structure so that it's the same regardless of if it's
built with 32-bit or 64-bit userlands.  This is hard where you have
pointers, both otherwise is usually possible with a bit of planning.
You especially need to watch out for long which is a different size on
32-bit/64-bit userlands and also for int64_t which can align differently
depending on the architecture.  If you can do a printf of the struct
size with a variety of arches and they're all the same then good!  amd64,
i386, mips64 (n32), sparc would probably cover the range of cases to
test on (a compile test will do if you look at the generated code for
what is passed to printf).  The general rule is if we can avoid touching
compat/netbsd32 then life is easier!

The issue with in_nbrinfo and in6_nbrinfo is that there's a "long" in
the structure, so this has different sizes depending on your native long
size.

I _think_ this is the is value out of the la_asked member of struct
llentry which is a uint16_t so we can just make it an int the your
structures will align nicely.  In both cases the ifname name is 16
bytes.  For in_nbrinfo in_addr is effectively an int so we have just
four ints after the ifname.  For in6_nbrinfo the in6_addr is 128 bytes
so aligns nicely, then a couple more ints after that.

If "asked" is from struct llentry then the attached patch should work
without requiring any compat32 support.  If you're happy with this, I'll
test a bit more then commit.

Cheers,
Simon.

Index: netinet/in_var.h
===
RCS file: /cvsroot/src/sys/netinet/in_var.h,v
retrieving revision 1.98
diff -d -p -u -r1.98 in_var.h
--- netinet/in_var.h11 Sep 2020 15:22:12 -  1.98
+++ netinet/in_var.h15 Jan 2021 02:18:01 -
@@ -118,7 +118,7 @@ struct in_ifaddr {
 struct in_nbrinfo {
char ifname[IFNAMSIZ];  /* if name, e.g. "en0" */
struct in_addr addr;/* IPv4 address of the neighbor */
-   longasked;  /* number of queries already sent for this addr 
*/
+   int asked;  /* number of queries already sent for this addr 
*/
int state;  /* reachability state */
int expire; /* lifetime for NDP state transition */
 };
Index: netinet6/nd6.h
===
RCS file: /cvsroot/src/sys/netinet6/nd6.h,v
retrieving revision 1.91
diff -d -p -u -r1.91 nd6.h
--- netinet6/nd6.h  11 Sep 2020 15:03:33 -  1.91
+++ netinet6/nd6.h  15 Jan 2021 02:18:01 -
@@ -83,7 +83,7 @@ struct nd_kifinfo {
 struct in6_nbrinfo {
char ifname[IFNAMSIZ];  /* if name, e.g. "en0" */
struct in6_addr addr;   /* IPv6 address of the neighbor */
-   longasked;  /* number of queries already sent for this addr 
*/
+   int asked;  /* number of queries already sent for this addr 
*/
int isrouter;   /* if it acts as a router */
int state;  /* reachability state */
int expire; /* lifetime for NDP state transition */


Re: CVS commit: src/sys/compat/netbsd32

2021-01-14 Thread Roy Marples

On 14/01/2021 11:03, Simon Burge wrote:

Sure, I will have a look.  Anything IPv6 related I might need a helping
hand to get a test case though :).


As they share a similar structure, you solve one you likely solve the other.
I can assume you have working IPv4 ;)

Roy


Re: CVS commit: src/distrib/sets/lists/debug

2021-01-14 Thread Paul Goyette

Module Name:src
Committed By:   pgoyette
Date:   Thu Jan 14 19:07:03 UTC 2021

Modified Files:
src/distrib/sets/lists/debug: mi

Log Message:
/home/paul/XXX.txt


Crap - meant to include the text file...  Here's the good log info...


Update sets lists to accomodate KERNEL_DIR.  When both KERNEL_DIR and
MKDEBUG are defined, we create an empty $DESTDIR/usr/libdata/debug/netbsd/
directory.

Should fix ``build.sh release'' issue reported in kern/55923

XXX Since nothing ever seems to populate this directory, perhaps we should
XXX simply prevent its creation?  If we do create it, should its creation
XXX perhaps be conditioned on MKKDEBUG rather than MKDEBUG?

XXX There is still another problem with ``build.sh install-image'' but I
XXX open a new PR for that.

On Thu, 14 Jan 2021, Paul Goyette wrote:


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/compat/netbsd32

2021-01-14 Thread Simon Burge
Roy Marples wrote:

> On 14/01/2021 08:00, Simon Burge wrote:
> > Module Name:src
> > Committed By:   simonb
> > Date:   Thu Jan 14 08:00:45 UTC 2021
> > 
> > Modified Files:
> > src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h
> > 
> > Log Message:
> > Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with compat32 now.
> > XXX: FSSIOCSET50 and FSSIOCGET50 are not (yet) handled.
>
> Could I prompt you into looking at SIOCGNBRINFO (arp -a) and SIOCGNBRINFO_IN6 
> (ndp -a) please?
>
> I could never get that working.

Sure, I will have a look.  Anything IPv6 related I might need a helping
hand to get a test case though :).

Cheers,
Simon.


Re: CVS commit: src/sys/compat/netbsd32

2021-01-14 Thread Roy Marples

On 14/01/2021 08:00, Simon Burge wrote:

Module Name:src
Committed By:   simonb
Date:   Thu Jan 14 08:00:45 UTC 2021

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h

Log Message:
Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with compat32 now.
XXX: FSSIOCSET50 and FSSIOCGET50 are not (yet) handled.


Could I prompt you into looking at SIOCGNBRINFO (arp -a) and SIOCGNBRINFO_IN6 
(ndp -a) please?


I could never get that working.

Thanks

Roy


Re: CVS commit: src/usr.bin/xlint/lint1

2021-01-09 Thread Roland Illig

On 09.01.2021 17:42, Martin Husemann wrote:

On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote:

I guess a simple "make clean && make" will clear up the situation.


Not quite, "make clean" will not remove the old ops.c file in the objdir,
you need to manually kill it (or just remove all lint objdirs completely).

Please add an entry to src/UPDATING, I would suggest something like:

find $OBJDIR -type d -name \*lint\* | xargs rm -rf


Thanks for the suggestion, I first did that.  I was unsatisfied though
that people would actively have to read src/UPDATING.

Therefore, after reproducing the problem locally, I renamed ops.c to
oper.c, after which the build ran successfully.

Roland


Re: CVS commit: src/usr.bin/xlint/lint1

2021-01-09 Thread Martin Husemann
On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote:
> I guess a simple "make clean && make" will clear up the situation.

Not quite, "make clean" will not remove the old ops.c file in the objdir,
you need to manually kill it (or just remove all lint objdirs completely).

Please add an entry to src/UPDATING, I would suggest something like:

find $OBJDIR -type d -name \*lint\* | xargs rm -rf

Martin


Re: CVS commit: src/usr.bin/xlint/lint1

2021-01-09 Thread Roland Illig

On 09.01.2021 12:42, Jared McNeill wrote:

Not sure if it is this exact change, but I am no longer able to build
tools on Ubuntu 20.04.1:

--- lint1 ---
#  link  lint1/lint1
/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'


That's weird for several reasons:

1. The word STRUCT_ASSIGN no longer appears in the whole source tree, as
I removed the macro.

2. The compiler should have already caught this "implicit function
declaration" with -Werror and never let the linker see this.

I guess a simple "make clean && make" will clear up the situation.

Roland


Re: CVS commit: src/usr.bin/xlint/lint1

2021-01-09 Thread Jared McNeill
Not sure if it is this exact change, but I am no longer able to build 
tools on Ubuntu 20.04.1:


--- lint1 ---
#  link  lint1/lint1
cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 
-I/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/include/compat 
-I/home/jmcneill/netbsd/cvs-src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 
-D_FILE_OFFSET_BITS=64 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1 -I. 
-DPASS=\"lint1.h\" 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../arch/aarch64 
-I/home/jmcneill/netbsd/cvs-src/tools/lint1/../../usr.bin/xlint/lint1/../common 
-o lint1 cgram.lo decl.lo emit.lo emit1.lo err.lo func.lo init.lo 
inittyp.lo main1.lo mem.lo mem1.lo ops.lo print.lo scan.lo tree.lo 
tyname.lo 
-L/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/lib 
-lnbcompat -lrt -lz -lm

/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'
collect2: error: ld returned 1 exit status
*** [lint1] Error code 1

nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1
1 error

nbmake[3]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1

nbmake[2]: stopped in /home/jmcneill/netbsd/cvs-src/tools/lint1

*** Failed target:  dependall-lint1
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; 
shift; case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this=""; 
real="/home/jmcneill/netbsd/cvs-src/tools" ;; *) this="${dir}/"; 
real="/home/jmcneill/netbsd/cvs-src/tools/${dir}" ;; esac; 
show=${this:-.}; echo "${target} ===> ${show%/}${1:+ (with: $@)}"; cd 
"${real}" && 
/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/bin/nbmake 
_THISDIR_="${this}" "$@" ${target}; }; _makedirtarget lint1 dependall

*** Error code 2

Stop.
nbmake[1]: stopped in /home/jmcneill/netbsd/cvs-src/tools
*** [build_install] Error code 1

nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools
1 error

nbmake: stopped in /home/jmcneill/netbsd/cvs-src/tools

ERROR: Failed to make build_install in "tools"
*** BUILD ABORTED ***


On Tue, 5 Jan 2021, Roland Illig wrote:


Module Name:src
Committed By:   rillig
Date:   Tue Jan  5 23:50:29 UTC 2021

Modified Files:
src/usr.bin/xlint/lint1: Makefile op.h ops.def
Added Files:
src/usr.bin/xlint/lint1: ops.c
Removed Files:
src/usr.bin/xlint/lint1: Makefile.ops-c Makefile.ops-h mkops

Log Message:
lint: clean up generation of the operator tables

Instead of running a shell program that runs an AWK program that
generates the two files ops.c and ops.h, just define the operator tables
once in ops.def and use these definitions flexibly in ops.c and op.h.


To generate a diff of this commit:
cvs rdiff -u -r1.55 -r1.56 src/usr.bin/xlint/lint1/Makefile
cvs rdiff -u -r1.3 -r0 src/usr.bin/xlint/lint1/Makefile.ops-c \
   src/usr.bin/xlint/lint1/Makefile.ops-h
cvs rdiff -u -r1.13 -r0 src/usr.bin/xlint/lint1/mkops
cvs rdiff -u -r1.9 -r1.10 src/usr.bin/xlint/lint1/op.h
cvs rdiff -u -r0 -r1.1 src/usr.bin/xlint/lint1/ops.c
cvs rdiff -u -r1.6 -r1.7 src/usr.bin/xlint/lint1/ops.def

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




Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-03 Thread Frank Kardel

Hi Roy !

That looks more semantics (the ones I know of - dynamic interface 
scanning is one of my NTPd parts)


preserving now.

So far I see no other issues from the pitfalls I know of.

Lets hope our kernel and other SO_RERRORS systems miss any

interface scan worthy events.

Frank


On 01/03/21 12:03, Roy Marples wrote:

On 02/01/2021 23:33, Frank Kardel wrote:

Hi Roy !

This may look like a better solution from the interface tracking side.

People have requested being able to disable dynamic interface updates 
completely.


This was implemented via the -U 0.


...


This patch seems (by visual inspection) to break that logic.

Also the behavior now fully relies in the routing message 
functionality which can be disabled


on serious procession errors - at that point the code robustness 
relies on the periodic


re-scanning - so I am not sure whether the periodic re-scanning 
should be completely


Valid points.

New patch sets disable_dynamic_updates if the -U 0 is given.
The only other code to touch disable_dynamic_updates is this
disable_dynamic_updates |= (sw_uid != 0);  /* also notifies routing 
message listener *


So this should be good now.

diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/cmd_args.c
--- a/external/bsd/ntp/dist/ntpd/cmd_args.c Sat Jan 02 12:39:33 
2021 +
+++ b/external/bsd/ntp/dist/ntpd/cmd_args.c Sun Jan 03 10:56:58 
2021 +

@@ -181,9 +181,11 @@
if (HAVE_OPT( UPDATEINTERVAL )) {
long val = OPT_VALUE_UPDATEINTERVAL;

-   if (val >= 0)
+   if (val >= 0) {
interface_interval = val;
-   else {
+   if (interface_interval == 0)
+   disable_dynamic_updates = 1;
+   } else {
fprintf(stderr,
"command line interface update 
interval %ld must not be negative\n",

val);
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c   Sat Jan 02 12:39:33 
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c   Sun Jan 03 10:56:58 
2021 +

@@ -455,8 +455,13 @@
 {
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+   /* route(4) overflow can be observed */
+   interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif

 #ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSun Jan 03 10:56:58 
2021 +

@@ -423,9 +423,11 @@
/*
 * Interface update timer
 */
-   if (interface_interval && interface_timer <= current_time) {
-   timer_interfacetimeout(current_time +
-   interface_interval);
+   if (!disable_dynamic_updates &&
+   interface_timer && interface_timer <= current_time) {
+   if (interface_interval)
+   timer_interfacetimeout(current_time +
+   interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}





Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-03 Thread Roy Marples

On 02/01/2021 23:33, Frank Kardel wrote:
Also the behavior now fully relies in the routing message functionality which 
can be disabled


on serious procession errors - at that point the code robustness relies on the 
periodic


re-scanning - so I am not sure whether the periodic re-scanning should be 
completely


disabled.


Could you expand on this please? It sounds like you want it to be user disabled 
but not for routing messages? I don't understand.


Roy


Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-03 Thread Roy Marples

On 02/01/2021 23:33, Frank Kardel wrote:

Hi Roy !

This may look like a better solution from the interface tracking side.

People have requested being able to disable dynamic interface updates 
completely.

This was implemented via the -U 0.


...


This patch seems (by visual inspection) to break that logic.

Also the behavior now fully relies in the routing message functionality which 
can be disabled


on serious procession errors - at that point the code robustness relies on the 
periodic


re-scanning - so I am not sure whether the periodic re-scanning should be 
completely


Valid points.

New patch sets disable_dynamic_updates if the -U 0 is given.
The only other code to touch disable_dynamic_updates is this
disable_dynamic_updates |= (sw_uid != 0);  /* also notifies routing message 
listener *


So this should be good now.

diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/cmd_args.c
--- a/external/bsd/ntp/dist/ntpd/cmd_args.c Sat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/cmd_args.c Sun Jan 03 10:56:58 2021 +
@@ -181,9 +181,11 @@
if (HAVE_OPT( UPDATEINTERVAL )) {
long val = OPT_VALUE_UPDATEINTERVAL;

-   if (val >= 0)
+   if (val >= 0) {
interface_interval = val;
-   else {
+   if (interface_interval == 0)
+   disable_dynamic_updates = 1;
+   } else {
fprintf(stderr,
"command line interface update interval %ld 
must not be negative\n",

val);
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c   Sat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c   Sun Jan 03 10:56:58 2021 +
@@ -455,8 +455,13 @@
 {
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+   /* route(4) overflow can be observed */
+   interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif

 #ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSun Jan 03 10:56:58 2021 +
@@ -423,9 +423,11 @@
/*
 * Interface update timer
 */
-   if (interface_interval && interface_timer <= current_time) {
-   timer_interfacetimeout(current_time +
-   interface_interval);
+   if (!disable_dynamic_updates &&
+   interface_timer && interface_timer <= current_time) {
+   if (interface_interval)
+   timer_interfacetimeout(current_time +
+   interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}



Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-02 Thread Frank Kardel

Hi Roy !

This may look like a better solution from the interface tracking side.

People have requested being able to disable dynamic interface updates 
completely.


This was implemented via the -U 0.

See man ntpd:

...

−U number, −−updateinterval=number
 interval in seconds between scans for new or dropped 
inter‐
 faces.  This option takes an integer number as its 
argument.


 Give the time in seconds between two scans for new or 
dropped

 interfaces.  For systems with routing socket support the
 scans will be performed shortly after the interface change
 has been detected by the system.  Use 0 to disable 
scanning.

 60 seconds is the minimum time between scans.

...

This patch seems (by visual inspection) to break that logic.

Also the behavior now fully relies in the routing message functionality 
which can be disabled


on serious procession errors - at that point the code robustness relies 
on the periodic


re-scanning - so I am not sure whether the periodic re-scanning should 
be completely


disabled.

Best regards,

  Frank


On 01/02/21 19:41, Roy Marples wrote:

On 02/01/2021 17:23, Roy Marples wrote:
That's a good point, with this we can now remove that forced sync on 
a timer approach.


Does this look ok?


Better patch:

diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c   Sat Jan 02 12:39:33 
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c   Sat Jan 02 18:39:34 
2021 +

@@ -455,8 +455,13 @@
 {
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+   /* route(4) overflow can be observed */
+   interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif

 #ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 
2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 18:39:34 
2021 +

@@ -423,9 +423,10 @@
/*
 * Interface update timer
 */
-   if (interface_interval && interface_timer <= current_time) {
-   timer_interfacetimeout(current_time +
-   interface_interval);
+   if (interface_timer && interface_timer <= current_time) {
+   if (interface_interval)
+   timer_interfacetimeout(current_time +
+   interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}




Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-02 Thread Roy Marples

On 02/01/2021 17:23, Roy Marples wrote:
That's a good point, with this we can now remove that forced sync on a timer 
approach.


Does this look ok?


Better patch:

diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c   Sat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_io.c   Sat Jan 02 18:39:34 2021 +
@@ -455,8 +455,13 @@
 {
/* Init buffer free list and stat counters */
init_recvbuff(RECV_INIT);
+#ifdef SO_RERROR
+   /* route(4) overflow can be observed */
+   interface_interval = 0;
+#else
/* update interface every 5 minutes as default */
interface_interval = 300;
+#endif

 #ifdef WORK_PIPE
addremove_io_fd = _addremove_io_fd;
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 18:39:34 2021 +
@@ -423,9 +423,10 @@
/*
 * Interface update timer
 */
-   if (interface_interval && interface_timer <= current_time) {
-   timer_interfacetimeout(current_time +
-   interface_interval);
+   if (interface_timer && interface_timer <= current_time) {
+   if (interface_interval)
+   timer_interfacetimeout(current_time +
+   interface_interval);
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}


Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-02 Thread Roy Marples

Hi Frank

On 02/01/2021 09:55, Frank Kardel wrote:

I doubt that the explicit draining is helpful here as it already happens


I was aware of that.
I was just trying to avoid excess timer interface timeouts if we don't get 
around to reading the next message in UPDATE_GRACE time.

Let's see what upstream says.

Also the ntp_io system will periodically refresh it interface lists in time as 
it was explicitly designed to be robust against lost messages from the routing 
socket.


That's a good point, with this we can now remove that forced sync on a timer 
approach.


Does this look ok?

diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_timer.c
--- a/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 12:39:33 2021 +
+++ b/external/bsd/ntp/dist/ntpd/ntp_timer.cSat Jan 02 17:19:28 2021 +
@@ -423,9 +423,18 @@
/*
 * Interface update timer
 */
-   if (interface_interval && interface_timer <= current_time) {
-   timer_interfacetimeout(current_time +
-   interface_interval);
+   if (interface_timer && interface_timer <= current_time) {
+#ifdef SO_RERROR
+   /*
+* Because we can catch route(4) overflow, there is no
+* need to update interfaces every interface_interval.
+*/
+   interface_timer = 0;
+#else
+   if (interface_interval)
+   timer_interfacetimeout(current_time +
+   interface_interval);
+#endif
DPRINTF(2, ("timer: interface update\n"));
interface_update(NULL, NULL);
}

We should try to keep the differences to the up-stream code as little as 
possible. Especially when the upstream code already handles the situation 
reasonably the is no need for additional code.


Agreed.
I already submitted the diff upstream, but will adjust it to remove the forced 
refresh.



Happy new year!


And the same to you!

Roy


Re: CVS commit: src/external/bsd/ntp/dist/ntpd

2021-01-02 Thread Frank Kardel

Hi Roy !

I doubt that the explicit draining is helpful here as it already happens

in the outer loop processing any routing socket input. All that is happening

in the routing messages processing path is to call 
timer_interfacetimeout(current_time + UPDATE_GRACE) and


this is robust for multiple calls.

Ignoring ENOBUFS was ok here due to the automatic periodic interface 
updates. calling timer_interfacetimeout(current_time + UPDATE_GRACE)


is also possible if you expect a single ENOBUFS within UPDATE_GRACE 
seconds. But there is no need o special case flushing the routing socket 
here. There is no functional improvement except for


save a few cycles in the overflow case.

Also the ntp_io system will periodically refresh it interface lists in 
time as it was explicitly designed to be robust against lost messages 
from the routing socket.


We should try to keep the differences to the up-stream code as little as 
possible. Especially when the upstream code already handles the 
situation reasonably the is no need for additional code.


Happy new year!

Frank


On 01/01/21 18:21, Roy Marples wrote:

cvs rdiff -u -r1.27 -r1.28 src/external/bsd/ntp/dist/ntpd/ntp_io.c




Re: CVS commit: src

2021-01-02 Thread Ryo Shimizu


>sys/external/gpl2/dts/dist is meant for upstream dts files only. Do 
>you mind  moving this to sys/arch/arm/dts with the other custom dts files?

Ah, I Understood. Sorry, I didn't have a good grasp of the
sys/external/gpl2/dts/dist/arch policy.
I will move it to sys/arch/arm/dts.

Thanks!
-- 
ryo shimizu


Re: CVS commit: src/distrib/sets/lists/games

2021-01-01 Thread Paul Goyette

Please also add the appropriate entry to src/distrib/sets/lists/debug.mi
for those of us who build with MKDEBUG=YES

:)



On Sat, 2 Jan 2021, Nathanial Sloss wrote:


Module Name:src
Committed By:   nat
Date:   Sat Jan  2 03:24:02 UTC 2021

Modified Files:
src/distrib/sets/lists/games: mi

Log Message:
Add testpat(6) to the games set.


To generate a diff of this commit:
cvs rdiff -u -r1.59 -r1.60 src/distrib/sets/lists/games/mi

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


!DSPAM:5fefe793123761591715016!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/external/bsd/unbound/lib/libunbound

2021-01-01 Thread Robert Elz
Date:Fri, 1 Jan 2021 20:38:36 +
From:"Roy Marples" 
Message-ID:  <20210101203836.2cadcf...@cvs.netbsd.org>

  | Modified Files:
  | src/external/bsd/unbound/lib/libunbound: Makefile
  |
  | Log Message:
  | libunbound: Now we use libevent, don't build mini_event or winsock_event.

That changes the ABI of  the library (libunbound) and so at the very
least would require a major version bump.

It also breaks the build.

Please revert, and also (and this applies to *everyone*) please do release
builds BEFORE committing changes which can (even remotely possibly) affect
the rest of the build (which more or less means any change other than to
doc - and even there if any doc is new or deleted).

kre



Re: CVS commit: src

2021-01-01 Thread Jared McNeill

Hi!

sys/external/gpl2/dts/dist is meant for upstream dts files only. Do 
you mind  moving this to sys/arch/arm/dts with the other custom dts files?


Thanks!
Jared


On Fri, 1 Jan 2021, Ryo Shimizu wrote:


Module Name:src
Committed By:   ryo
Date:   Fri Jan  1 07:41:46 UTC 2021

Modified Files:
src/distrib/sets/lists/dtb: ad.aarch64 ad.aarch64eb
src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic: Makefile
Added Files:
src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic:
meson-g12b-odroid-n2-plus.dts

Log Message:
add dts for odroid-N2 plus.

meson-g12b-odroid-n2-plus.dts of linux is not optimized for the odroid-N2plus 
CPU clock.
and the dts for odroid-n2-plus in the hardkernel repository is  significantly 
changed,
so cannot be imported without modification. Therefore, a simple 
meson-g12b-odroid-n2-plus.dts
has been added based on "meson-g12b-odroid-n2.dts" with only the cpu_opp_table 
and
regulator table changed.


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/distrib/sets/lists/dtb/ad.aarch64
cvs rdiff -u -r1.2 -r1.3 src/distrib/sets/lists/dtb/ad.aarch64eb
cvs rdiff -u -r1.1.1.7 -r1.2 \
   src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic/Makefile
cvs rdiff -u -r0 -r1.1 \
   
src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2-plus.dts

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/arm/rockchip

2021-01-01 Thread Jared McNeill
Oops. The change was to make sure that a devicetree node with a 
"rockchip,grf" property on a device type that doesn't provide a config 
struct doesn't deref a NULL ptr.


On Fri, 1 Jan 2021, Jared D. McNeill wrote:


Module Name:src
Committed By:   jmcneill
Date:   Fri Jan  1 11:44:41 UTC 2021

Modified Files:
src/sys/arch/arm/rockchip: rk_i2s.c

Log Message:
rk_i2s.c


To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/rockchip/rk_i2s.c

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




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

2020-12-22 Thread matthew green
"Roland Illig" writes:
> Module Name:  src
> Committed By: rillig
> Date: Tue Dec 22 08:10:39 UTC 2020
>
> Modified Files:
>   src/usr.bin/make: parse.c

i'm not sure which change did it (but before this one for sure),
but my builds crash early now (still trying to bootstrap nbmake):

cc -o nbmake *.o
assertion "*line_end == '\n'" failed: file "/usr/src/usr.bin/make/parse.c", 
line 2844, function "ParseGetLine"
[1]   Abort trap (core dumped) "${make}" -m ${TOP}/share/mk -s -B -f- _x_ <<...

ERROR: bomb_getmakevar MAKECONF: /tmp/nbbuild14989/nbmake failed

please fix :-)


.mrg.


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

2020-12-14 Thread Christos Zoulas
In article <20201213212746.3cfc3f...@cvs.netbsd.org>,
Roland Illig  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  rillig
>Date:  Sun Dec 13 21:27:46 UTC 2020
>
>Modified Files:
>   src/usr.bin/make: for.c meta.c parse.c var.c
>
>Log Message:
>make(1): replace %zu with %u in printf calls
>
>This is needed to compile bmake with GCC 2.8.1 on SunOS 5.9.
>
>To support ancient systems like this, the whole code of usr.bin/make is
>supposed to use only ISO C90 features, except for filemon, which is not
>used on these systems.

Please revert! This breaks everyone else. %zu is the format to
print size_t.  Last I checked SunOS 5.9 has been dead since 2014
and whoever is still using it might as well install a new compiler,
or tie the box at the end of a long chain so it can find its true
calling. If you really want to support it instead define MAKE_FMT_SIZE_T
and conditionalize it properly for "ancient OS", windows, cygwin,
mingwin, and regular folks (this does not even handle "ancient os"):

https://github.com/file/file/blob/master/src/file.h#L55

I am still against it though...

christos



Re: CVS commit: src/external/gpl2/diffutils/dist/src

2020-12-12 Thread Joerg Sonnenberger
On Sun, Dec 13, 2020 at 12:04:40AM +, Roy Marples wrote:
> Module Name:  src
> Committed By: roy
> Date: Sun Dec 13 00:04:40 UTC 2020
> 
> Modified Files:
>   src/external/gpl2/diffutils/dist/src: util.c
> 
> Log Message:
> diffutils: execl requires a NULL sentinel

Strictly speaking, this needs a cast to work properly. It really needs
to be a pointer and NULL isn't necessarily one.

Joerg


Re: CVS commit: src/sys/dev/pci/ixgbe

2020-12-10 Thread SAITOH Masanobu

On 2020/12/11 14:01, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Fri Dec 11 05:01:19 UTC 2020

Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c ixgbe_type.h

Log Message:
  Don't use EIMC_OTHER bit because it's read only other than 82598.

  Documents say:

   82598:
  All of bit 31(OTHER bit) of EIxx are reserved. In reality, at least
 EIMS_OTHER and EIMC_OTHER exist and the OTHER interrupt doesn't work
 without EIMS_OTHER.

   Other than 82598:


+  EICR's bit 31 is defined and other EIXX's bit 31 are reserved.
+  In reality,


  EIMS_OTHER is read only and EIMC_OTHER doesn't exist. If one of
 bit 29..16 is set, EIMS_OTHER is set to 1 (Note that bit 30(TCP timer
 isn't included)). Even if write bit 31 of EIMC to 1, it's ignored
 (EIMS_OTHER doesn't set).

  We introduced new spin mutex in ixgbe.c rev. 1.260, so it's OK to remove
EIMC_OTHER stuff. We already set EIMS_OTHER in if_init(), so keep it for
82598. No functional change other than 82598.

  Another solution is to control bit 30..16 directly to mask/unmask interrupt
instead of the mutex.

TODO:
   Some MSI-X interrupt(LSC, module insertion/removal etc.)'s mask/unmask
   code between ixgbe_msix_admin() and ixgbe_handle_admin() may be wrong.
   It'll be fixed later.


To generate a diff of this commit:
cvs rdiff -u -r1.261 -r1.262 src/sys/dev/pci/ixgbe/ixgbe.c
cvs rdiff -u -r1.45 -r1.46 src/sys/dev/pci/ixgbe/ixgbe_type.h

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




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)


Re: CVS commit: src/external/gpl3/gdb/dist/gdb

2020-12-10 Thread Kamil Rytarowski
On 10.12.2020 08:14, Rin Okuyama wrote:
> Module Name:  src
> Committed By: rin
> Date: Thu Dec 10 07:14:58 UTC 2020
> 
> Modified Files:
>   src/external/gpl3/gdb/dist/gdb: nbsd-nat.c
> 
> Log Message:
> Fix arm, for which PT_STEP is defined but unimplemented.
> 
> XXX
> Stop exposing PT_STEP to userland for arm?
> 


Yes, please remove it from headers for arm. This was a hack for DTrace
as far as I recall, to expose PT_STEP that way and get DTrace building.

Then, please restore nbsd-nat.c to the previous state.



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src/sys/netinet

2020-12-04 Thread Jason Thorpe


> On Dec 4, 2020, at 8:57 AM, Christos Zoulas  wrote:
> 
> In article <20201204004439.90c25f...@cvs.netbsd.org>,
> Jason R Thorpe  wrote:
>> -=-=-=-=-=-
>> 
>> Module Name: src
>> Committed By:thorpej
>> Date:Fri Dec  4 00:44:39 UTC 2020
>> 
>> Modified Files:
>>  src/sys/netinet: files.ipfilter
>> 
>> Log Message:
>> Build ip_sync.c with -Wno-error to avoid failing due to excessive stack
>> usage.
> 
> Can you please make this more specific? Like -Wno-error=foo?

Feel free to try.  -Wno-error=stack-usage produced an error for me.

-- thorpej



Re: CVS commit: src/sys/netinet

2020-12-04 Thread Christos Zoulas
In article <20201204004439.90c25f...@cvs.netbsd.org>,
Jason R Thorpe  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  thorpej
>Date:  Fri Dec  4 00:44:39 UTC 2020
>
>Modified Files:
>   src/sys/netinet: files.ipfilter
>
>Log Message:
>Build ip_sync.c with -Wno-error to avoid failing due to excessive stack
>usage.

Can you please make this more specific? Like -Wno-error=foo?

christos



Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

2020-11-29 Thread Yorick Hardy
On 2020-11-28, Yorick Hardy wrote:
> Module Name:  src
> Committed By: yhardy
> Date: Sat Nov 28 22:53:06 UTC 2020
> 
> Modified Files:
>   src/external/cddl/osnet/dist/uts/common/fs/zfs: vdev_disk.c
> 
> Log Message:
> Use vn_close to release the vnodes in the error handling blocks, since
> the vnodes were opened for writing. Fix proposed on current-users
> and improved by hannken@.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.18 -r1.19 \
> src/external/cddl/osnet/dist/uts/common/fs/zfs/vdev_disk.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.


Oops, that should have been "proposed on tech-kern":

 http://mail-index.netbsd.org/tech-kern/2020/11/28/msg026984.html

-- 
Kind regards,

Yorick Hardy


Re: CVS commit: src/sys/arch/arm/arm32

2020-11-21 Thread Rin Okuyama

Excellent! Thank you so much for finding out and fixing this!

Full ATF successfully completed for Raspberry Pi 2b, which formerly
crashed due to "anon != NULL && anon->an_ref != 0" panic.

Now, ATF is running on Cubietruck and Raspberry Pi Zero W.

Thanks,
rin

On 2020/11/22 4:44, Nick Hudson wrote:

Module Name:src
Committed By:   skrll
Date:   Sat Nov 21 19:44:52 UTC 2020

Modified Files:
src/sys/arch/arm/arm32: cpuswitch.S

Log Message:
Ensure that r5 contains curlwp before DO_AST_AND_RESTORE_ALIGNMENT_FAULTS
in lwp_trampoline as required by the move to make ASTs operate per-LWP
rather than per-CPU.

Thanks to martin@ for bisecting the amap corruption he was seeing and
testing this fix.


To generate a diff of this commit:
cvs rdiff -u -r1.103 -r1.104 src/sys/arch/arm/arm32/cpuswitch.S

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


Re: CVS commit: src/sys

2020-11-12 Thread Erik Fair
Please pull up to netbsd-8 and netbsd-9 release branches.

> On Nov 11, 2020, at 23:44, Simon Burge  wrote:
> 
> Module Name:  src
> Committed By: simonb
> Date: Thu Nov 12 07:44:01 UTC 2020
> 
> Modified Files:
>   src/sys/conf: param.c
>   src/sys/kern: init_main.c
>   src/sys/sys: param.h
> 
> Log Message:
> Set a better default for MAXFILES on larger RAM machines if not
> otherwise specified the kernel config file.  Arbitary numbers are
> 20,000 files for 16GB RAM or more and 10,000 files for 1GB RAM or
> more.
> 
> TODO: Adjust this and other values totally dynamically.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.68 -r1.69 src/sys/conf/param.c
> cvs rdiff -u -r1.532 -r1.533 src/sys/kern/init_main.c
> cvs rdiff -u -r1.678 -r1.679 src/sys/sys/param.h
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 



Re: CVS commit: src

2020-11-12 Thread Joerg Sonnenberger
On Sun, Nov 08, 2020 at 09:56:48PM +, Nia Alarie wrote:
> Module Name:  src
> Committed By: nia
> Date: Sun Nov  8 21:56:48 UTC 2020
> 
> Modified Files:
>   src/external/bsd/kyua-cli: Makefile.inc
>   src/external/ibm-public/postfix: Makefile.inc
>   src/external/public-domain/sqlite: Makefile.inc
>   src/external/public-domain/sqlite/bin: Makefile
>   src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
>   src/usr.sbin/makemandb: Makefile
> 
> Log Message:
> sqlite: do not build without multithreading support

So the core issue here is that it actually does two separate things. It
does not only enable threadsafety (which is good), but also enables the
worker thread support (which is bad). There is little reason for wanting
the latter in a general build, at least the way it is implemented right
now. Just doing the former is a lot less intrusive...

Joerg
diff -r 2bb2635be785 external/public-domain/sqlite/Makefile.inc
--- a/external/public-domain/sqlite/Makefile.incThu Nov 12 23:24:18 
2020 +0100
+++ b/external/public-domain/sqlite/Makefile.incThu Nov 12 23:28:36 
2020 +0100
@@ -15,6 +15,7 @@
-DHAVE_STRERROR_R=1 \
-DHAVE_USLEEP=1 \
-DHAVE_SYS_ENDIAN_H=1 \
+   -DSQLITE_THREADSAFE \
-DSQLITE_MAX_WORKER_THREADS=0 \
-DSQLITE_ENABLE_COLUMN_METADATA \
-DSQLITE_ENABLE_FTS3_PARENTHESIS \


Re: CVS commit: src

2020-11-12 Thread Rin Okuyama

On 2020/11/13 2:35, nia wrote:

I'll revert the commit shortly.


Thank you very much for your quick response.


I wasn't expecting such major breakage (obviously) and actually
did run a build but ran into different problems with libstdc++.


Yeah, this is why we need tests, and also listen to others before
making somewhat big changes. No one is perfect...

Thanks,
rin


Re: CVS commit: src

2020-11-12 Thread Martin Husemann
On Thu, Nov 12, 2020 at 07:58:13PM +, Taylor R Campbell wrote:
> But there's a snag with heimdal.
> 
> Heimdal exposes the sqlite3 library to clients via libgssapi.so which
> links against libkrb5.so which brings in libsqlite3.so.  So we get nice
> situations like this:
> 
> % ldd /pkg/2020Q2/bin/svn | grep sqlite   
> -lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0
> -lsqlite3.1 => /usr/lib/libsqlite3.so.1
> 
> This is also why the change to base sqlite3 affected, e.g., su(1).

How about making sqlite3 just a private lib statically linked into whatever
part of heimdahl actually needs it, and not exposing any symbols from it?

Martin


Re: CVS commit: src

2020-11-12 Thread Taylor R Campbell
> Date: Thu, 12 Nov 2020 11:21:43 -0800
> From: Jason Thorpe 
> 
> > On Nov 12, 2020, at 9:40 AM, nia  wrote:
> > 
> > For the record I'm just trying to fix things so that running
> > third-party software on NetBSD sucks less. If fewer third-party
> > libraries were exposed by the base system this wouldn't be
> > necessary.
> 
> Why do we even have sqlite in the base system in the first place?

apropos(1); a handful of other things also use it (heimdal, postfix).

I suggested that we leave the bells & whistles out of base sqlite3,
maybe even stop installing the .so symlink, and teach pkgsrc to just
use pkgsrc sqlite3 (with all bells & whistles included) rather than
base sqlite3 -- after all, sqlite3 is meant to be embedded and has
lots of optional bells & whistles that apropos(1) has no need of, so
it is silly to impose those costs on apropos(1) or make sqlite3 part
of the NetBSD API.

But there's a snag with heimdal.

Heimdal exposes the sqlite3 library to clients via libgssapi.so which
links against libkrb5.so which brings in libsqlite3.so.  So we get nice
situations like this:

% ldd /pkg/2020Q2/bin/svn | grep sqlite   
-lsqlite3.0 => /pkg/2020Q2/lib/libsqlite3.so.0
-lsqlite3.1 => /usr/lib/libsqlite3.so.1

This is also why the change to base sqlite3 affected, e.g., su(1).

I have no idea what heimdal does with sqlite3, but it puts us in a
pretty pickle: we can't reliably use pkgsrc sqlite3 on existing NetBSD
installs for packages that use gssapi, and we can't rely on sqlite3 in
existing NetBSD installs for packages that need newer/threaded/jsonned
sqlite3 as we often encounter.


Re: CVS commit: src

2020-11-12 Thread Jason Thorpe


> On Nov 12, 2020, at 9:40 AM, nia  wrote:
> 
> For the record I'm just trying to fix things so that running
> third-party software on NetBSD sucks less. If fewer third-party
> libraries were exposed by the base system this wouldn't be
> necessary.

Why do we even have sqlite in the base system in the first place?

-- thorpej



Re: CVS commit: src

2020-11-12 Thread nia
On Thu, Nov 12, 2020 at 05:35:44PM +, nia wrote:
> I'll revert the commit shortly.
> 
> I wasn't expecting such major breakage (obviously) and actually
> did run a build but ran into different problems with libstdc++.

For the record I'm just trying to fix things so that running
third-party software on NetBSD sucks less. If fewer third-party
libraries were exposed by the base system this wouldn't be
necessary.


Re: CVS commit: src

2020-11-12 Thread nia
I'll revert the commit shortly.

I wasn't expecting such major breakage (obviously) and actually
did run a build but ran into different problems with libstdc++.


Re: CVS commit: src

2020-11-12 Thread Rin Okuyama

On 2020/11/12 23:03, Rin Okuyama wrote:

The backtrace reads:

| (gdb) bt
| #0  0xfc2961bca308 in ?? ()
| #1  0xfc2961b9ec10 in __deregister_frame_info_bases ()
|    from /usr/lib/libgcc_s.so.1
| #2  0xf88425b4 in _rtld_call_function_void (obj=0xfc2962917400,
| addr=277254663434168) at /usr/src/libexec/ld.elf_so/rtld.h:514
| ...

The fault address is anon memory w/o exec permission when su exits:

| # pmap -p xxx
| ...
| FC2961BB1000  4K read/write    /altroot/lib/libgcc_s.so.1.0
| FC2961BB6000 40K read/write  [ anon ]
| FC2961BE6000 40K read/write  [ anon ]
| ...


Oops, correction: the fault address is not mapped when su exits;
FC2961BB6000 + 40K = FC2961BC.

The discussion thereafter does not change.

Thanks,
rin


Re: CVS commit: src

2020-11-12 Thread Rin Okuyama

On 2020/11/11 1:50, nia wrote:

On Tue, Nov 10, 2020 at 04:29:21PM +, Taylor R Campbell wrote:

Module Name:src
Committed By:   nia
Date:   Sun Nov  8 21:56:48 UTC 2020

Modified Files:
 src/external/bsd/kyua-cli: Makefile.inc
 src/external/ibm-public/postfix: Makefile.inc
 src/external/public-domain/sqlite: Makefile.inc
 src/external/public-domain/sqlite/bin: Makefile
 src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
 src/usr.sbin/makemandb: Makefile

Log Message:
sqlite: do not build without multithreading support

at least a few pkgsrc packages avoid base sqlite because it fails
this check, and it's probably a surprising performance penalty for
unsuspecting users


Why do we even expose NetBSD's libsqlite3.so to pkgsrc?  Why not just
have pkgsrc always use pkgsrc sqlite3, and change base to go back to
the smaller non-threaded sqlite3 with only the options the things in
base actually need?

Also: What is the performance penalty?  The sqlite3 documentation
(https://www.sqlite.org/faq.html#q6) suggests that _enabling_
SQLITE_THREADSAFE has a performance penalty, not the other way around.

It seems to me we've had a lot of problems over the years trying to
use base sqlite3 for everything in pkgsrc.  It's not clear to me that
any of the recent changes are helpful for the three things in base
that need sqlite3, and it's also not clear that they will help with
running newer pkgsrc on older NetBSD.


libevent is also problematic. Maybe there's just too many third-party
libraries that are exposed that sholdn't be.


A failure for cvs, suspected to be a fallout of threaded sqlite3 was
reported in port-arm@. See thread starts with:

http://mail-index.netbsd.org/port-arm/2020/11/12/msg007046.html

Also, I encountered another fallout: ``su -'' receives SIGSEGV when exits
(on aarch64, but I bet this is MI problem):

| $ su
| # exit
| $ su -
| # exit
| [2]   Segmentation fault (core dumped) su -

The backtrace reads:

| (gdb) bt
| #0  0xfc2961bca308 in ?? ()
| #1  0xfc2961b9ec10 in __deregister_frame_info_bases ()
|from /usr/lib/libgcc_s.so.1
| #2  0xf88425b4 in _rtld_call_function_void (obj=0xfc2962917400,
| addr=277254663434168) at /usr/src/libexec/ld.elf_so/rtld.h:514
| ...

The fault address is anon memory w/o exec permission when su exits:

| # pmap -p xxx
| ...
| FC2961BB1000  4K read/write/altroot/lib/libgcc_s.so.1.0
| FC2961BB6000 40K read/write  [ anon ]
| FC2961BE6000 40K read/write  [ anon ]
| ...

However, when su is running, libpthread is loaded at this address:

| # pmap -p xxx
| ...
| FC2961BB1000  4K read/write/altroot/lib/libgcc_s.so.1.0
| FC2961BB6000 40K read/write  [ anon ]
| FC2961BC 76K read/exec /altroot/lib/libpthread.so.1.4
| FC2961BD3000 64K   /altroot/lib/libpthread.so.1.4
| ...

su is not explicitly linked to libpthread, but it is loaded via libkrb5
via libpam. It registers its own deconstructor, however, it is unloaded
before su exits. Then, SIGSEGV takes place as a result.

IMO, this commit should be reverted ASAP. This kind of change needs more
tests, and discussion in appropriate lists before commit. Unfortunately,
the committer did not even carry out ``build.sh'' before commit (martin
fixed the build failure due to this). This is not what we, at least, I
expect our developers.

Thanks,
rin


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

2020-11-11 Thread Rin Okuyama

On 2020/11/12 6:52, matthew green wrote:

"Rin Okuyama" writes:

Module Name:src
Committed By:   rin
Date:   Tue Nov 10 21:40:07 UTC 2020

Modified Files:
src/sys/arch/arm/arm: cpu_exec.c

Log Message:
Test (epp->ep_esch->es_emul != _netbsd) instead of


nice, this is a step forward.

an optimisation on it could be to remove this test entirely
if neither MODULAR or COMAPT_NETBSD32 are set, as it will
always be false there.


Ah, yes. I will commit after some test. Thanks!

rin


re: CVS commit: src/sys/arch/arm/arm

2020-11-11 Thread matthew green
"Rin Okuyama" writes:
> Module Name:  src
> Committed By: rin
> Date: Tue Nov 10 21:40:07 UTC 2020
>
> Modified Files:
>   src/sys/arch/arm/arm: cpu_exec.c
>
> Log Message:
> Test (epp->ep_esch->es_emul != _netbsd) instead of

nice, this is a step forward.

an optimisation on it could be to remove this test entirely
if neither MODULAR or COMAPT_NETBSD32 are set, as it will
always be false there.

thanks.


.mrg.


Re: CVS commit: src

2020-11-10 Thread nia
On Tue, Nov 10, 2020 at 04:29:21PM +, Taylor R Campbell wrote:
> > Module Name:src
> > Committed By:   nia
> > Date:   Sun Nov  8 21:56:48 UTC 2020
> > 
> > Modified Files:
> > src/external/bsd/kyua-cli: Makefile.inc
> > src/external/ibm-public/postfix: Makefile.inc
> > src/external/public-domain/sqlite: Makefile.inc
> > src/external/public-domain/sqlite/bin: Makefile
> > src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
> > src/usr.sbin/makemandb: Makefile
> > 
> > Log Message:
> > sqlite: do not build without multithreading support
> > 
> > at least a few pkgsrc packages avoid base sqlite because it fails
> > this check, and it's probably a surprising performance penalty for
> > unsuspecting users
> 
> Why do we even expose NetBSD's libsqlite3.so to pkgsrc?  Why not just
> have pkgsrc always use pkgsrc sqlite3, and change base to go back to
> the smaller non-threaded sqlite3 with only the options the things in
> base actually need?
> 
> Also: What is the performance penalty?  The sqlite3 documentation
> (https://www.sqlite.org/faq.html#q6) suggests that _enabling_
> SQLITE_THREADSAFE has a performance penalty, not the other way around.
> 
> It seems to me we've had a lot of problems over the years trying to
> use base sqlite3 for everything in pkgsrc.  It's not clear to me that
> any of the recent changes are helpful for the three things in base
> that need sqlite3, and it's also not clear that they will help with
> running newer pkgsrc on older NetBSD.

libevent is also problematic. Maybe there's just too many third-party
libraries that are exposed that sholdn't be.


Re: CVS commit: src

2020-11-10 Thread Taylor R Campbell
> Module Name:src
> Committed By:   nia
> Date:   Sun Nov  8 21:56:48 UTC 2020
> 
> Modified Files:
> src/external/bsd/kyua-cli: Makefile.inc
> src/external/ibm-public/postfix: Makefile.inc
> src/external/public-domain/sqlite: Makefile.inc
> src/external/public-domain/sqlite/bin: Makefile
> src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
> src/usr.sbin/makemandb: Makefile
> 
> Log Message:
> sqlite: do not build without multithreading support
> 
> at least a few pkgsrc packages avoid base sqlite because it fails
> this check, and it's probably a surprising performance penalty for
> unsuspecting users

Why do we even expose NetBSD's libsqlite3.so to pkgsrc?  Why not just
have pkgsrc always use pkgsrc sqlite3, and change base to go back to
the smaller non-threaded sqlite3 with only the options the things in
base actually need?

Also: What is the performance penalty?  The sqlite3 documentation
(https://www.sqlite.org/faq.html#q6) suggests that _enabling_
SQLITE_THREADSAFE has a performance penalty, not the other way around.

It seems to me we've had a lot of problems over the years trying to
use base sqlite3 for everything in pkgsrc.  It's not clear to me that
any of the recent changes are helpful for the three things in base
that need sqlite3, and it's also not clear that they will help with
running newer pkgsrc on older NetBSD.


Re: CVS commit: src/share/mk

2020-11-09 Thread Rin Okuyama

On 2020/11/10 1:15, Christos Zoulas wrote:

- when we need to run ctfconvert, go through an intermediate ${.TARGET}.o
   file, instead of writing directly to ${.TARGET} and then overwriting
   ${.TARGET} with ctfconvert. This avoids build failures after a build
   got interrupted (the "partially built from C" scourge).


Thanks, I wanted this!

rin


Re: CVS commit: src

2020-11-08 Thread Kamil Rytarowski
On 08.11.2020 22:56, Nia Alarie wrote:
> Module Name:  src
> Committed By: nia
> Date: Sun Nov  8 21:56:48 UTC 2020
> 
> Modified Files:
>   src/external/bsd/kyua-cli: Makefile.inc
>   src/external/ibm-public/postfix: Makefile.inc
>   src/external/public-domain/sqlite: Makefile.inc
>   src/external/public-domain/sqlite/bin: Makefile
>   src/external/public-domain/sqlite/lib: Makefile sqlite3.pc.in
>   src/usr.sbin/makemandb: Makefile
> 
> Log Message:
> sqlite: do not build without multithreading support
> 
> at least a few pkgsrc packages avoid base sqlite because it fails
> this check, and it's probably a surprising performance penalty for
> unsuspecting users
> 

I'm getting:

dependall ===> usr.sbin/makemandb
nbmake[6]: nbmake[6]: don't know how to make -ltermlib. Stop
nbmake[6]: stopped in /usr/src/usr.sbin/makemandb



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src

2020-11-08 Thread Kamil Rytarowski
On 08.11.2020 17:55, Christos Zoulas wrote:
> In article <20201108145236.3a009f...@cvs.netbsd.org>,
> Kamil Rytarowski  wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Sun Nov  8 14:52:36 UTC 2020
>>
>> Modified Files:
>>  src: BUILDING
>>  src/distrib/sets: sets.subr
>>  src/doc: BUILDING.mdoc
>>  src/share/man/man5: mk.conf.5
>>  src/share/mk: bsd.README bsd.man.mk bsd.own.mk
>>
>> Log Message:
>> Remove the support for MKCATPAGES
>>
>> It was optional since 1999 and disabled by default since 2012.
>>
>> Proposed on tech-userlevel@.
> 
> What about the sets?
> 
> christos
> 

I'm test-building a local patch removing the cat files, directories and
a few other remnants.

Once it will be done, I will land it.



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src

2020-11-08 Thread Christos Zoulas
In article <20201108145236.3a009f...@cvs.netbsd.org>,
Kamil Rytarowski  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  kamil
>Date:  Sun Nov  8 14:52:36 UTC 2020
>
>Modified Files:
>   src: BUILDING
>   src/distrib/sets: sets.subr
>   src/doc: BUILDING.mdoc
>   src/share/man/man5: mk.conf.5
>   src/share/mk: bsd.README bsd.man.mk bsd.own.mk
>
>Log Message:
>Remove the support for MKCATPAGES
>
>It was optional since 1999 and disabled by default since 2012.
>
>Proposed on tech-userlevel@.

What about the sets?

christos



Re: CVS commit: src/sys

2020-11-07 Thread Paul Goyette

Thanks for checking!

I agree with your proposed changes.  If noone else objects, please
go ahead and commit.


On Sun, 8 Nov 2020, Rin Okuyama wrote:


Thanks Paul for finding out the bug!

Then, compat_netbsd32 and compat_netbsd32_coredump modules are
successfully load for kernel without COMPAT_NETBSD32 option.

However, OABI binaries still do not work. I found this is due to
there remains ``#ifdef COMPAT_NETBSD32'' codes in sys/arch/arm.

By fixing them, OABI binaries work and dump valid core files!

I changed two files.

(1) arm_netbsd_elf32_probe() in arm/cpu_exec.c

Previously, determine whether emulation is native or netbsd32 by
testing ``epp->ep_esch->es_emul == _netbsd32''. This requires
COMPAT_NETBSD32 option. However, we can use
``epp->ep_esch->es_emul != _netbsd'' for this purpose.

(2) arm_netbsd_elf32_coredump_setup() in arm/core_machdep.c

This seems simply a mistake; kernel sets EABI flag to OABI core
files. We can remove entire COMPAT_NETBSD32 codes.

I will commit them soon if there's no objection.

Thanks,
rin

On 2020/11/08 6:53, Paul Goyette wrote:

Thanks for fixing ...

On Sat, 7 Nov 2020, Christos Zoulas wrote:


/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7


christos


On Nov 7, 2020, at 4:27 PM, Paul Goyette  wrote:

OK, I think I found the problem, but I don't know how to solve it...

All of the undefined symbols are supposed to be provided by

.../sys/arch/arm/arm32/netbsd32_machdep.c

but there is no netbsd32_machdep.o included in the compat_netbsd32
module.?? This file should be included by the following code in 
.../sys/modules/compat_netbsd32/Makefile


.if ${MACHINE_ARCH} == "arm"
.PATH:?? ${S}/arch/arm/arm32
SRCS+=?? netbsd32_machdep.c
.endif

but it seems not to work (or at least, it doesn't do what it was
intended to do).






On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.?? But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

?? modload compat_netbsd32
?? modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

?? #include 
?? int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD?? 9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov?? 5 20:26:39 JST 
2020 rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf

# modload compat_netbsd32
[?? 29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_vm_default_addr' not found
[?? 29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_machdep_md_init' not found
[?? 29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_sendsig' not found
[?? 29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `cpu_mcontext32_validate' not found
[?? 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `cpu_setmcontext32' not found
[?? 29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_machdep_md_fini' not found
[?? 29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `startlwp32' not found
[?? 29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `cpu_getmcontext32' not found
[?? 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `machine32' not found
[?? 29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: 
symbol `netbsd32_sysarch' not found
[?? 29.7318320] WARNING: module error: unable to affix module 
`compat_netbsd32', error 8

modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in 
files

not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin






++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail 
addresses: |
| (Retired)?? | FA29 0E3B 35AF E8AE 6651 | 
p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org 
|

++--+---+





++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail 
addresses: |
| 

Re: CVS commit: src/sys

2020-11-07 Thread Rin Okuyama

Thanks Paul for finding out the bug!

Then, compat_netbsd32 and compat_netbsd32_coredump modules are
successfully load for kernel without COMPAT_NETBSD32 option.

However, OABI binaries still do not work. I found this is due to
there remains ``#ifdef COMPAT_NETBSD32'' codes in sys/arch/arm.

By fixing them, OABI binaries work and dump valid core files!

I changed two files.

(1) arm_netbsd_elf32_probe() in arm/cpu_exec.c

Previously, determine whether emulation is native or netbsd32 by
testing ``epp->ep_esch->es_emul == _netbsd32''. This requires
COMPAT_NETBSD32 option. However, we can use
``epp->ep_esch->es_emul != _netbsd'' for this purpose.

(2) arm_netbsd_elf32_coredump_setup() in arm/core_machdep.c

This seems simply a mistake; kernel sets EABI flag to OABI core
files. We can remove entire COMPAT_NETBSD32 codes.

I will commit them soon if there's no objection.

Thanks,
rin

On 2020/11/08 6:53, Paul Goyette wrote:

Thanks for fixing ...

On Sat, 7 Nov 2020, Christos Zoulas wrote:


/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7


christos


On Nov 7, 2020, at 4:27 PM, Paul Goyette  wrote:

OK, I think I found the problem, but I don't know how to solve it...

All of the undefined symbols are supposed to be provided by

.../sys/arch/arm/arm32/netbsd32_machdep.c

but there is no netbsd32_machdep.o included in the compat_netbsd32
module.  This file should be included by the following code in 
.../sys/modules/compat_netbsd32/Makefile

.if ${MACHINE_ARCH} == "arm"
.PATH:  ${S}/arch/arm/arm32
SRCS+=  netbsd32_machdep.c
.endif

but it seems not to work (or at least, it doesn't do what it was
intended to do).






On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

    modload compat_netbsd32
    modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

    #include 
    int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module `compat_netbsd32', 
error 8
modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin

!DSPAM:5fa3f309175521945872603!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+





++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: CVS commit: src/sys

2020-11-07 Thread Paul Goyette

Thanks for fixing ...

On Sat, 7 Nov 2020, Christos Zoulas wrote:


/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7


christos


On Nov 7, 2020, at 4:27 PM, Paul Goyette  wrote:

OK, I think I found the problem, but I don't know how to solve it...

All of the undefined symbols are supposed to be provided by

.../sys/arch/arm/arm32/netbsd32_machdep.c

but there is no netbsd32_machdep.o included in the compat_netbsd32
module.  This file should be included by the following code in 
.../sys/modules/compat_netbsd32/Makefile

.if ${MACHINE_ARCH} == "arm"
.PATH:  ${S}/arch/arm/arm32
SRCS+=  netbsd32_machdep.c
.endif

but it seems not to work (or at least, it doesn't do what it was
intended to do).






On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

modload compat_netbsd32
modload compat_netbsd32_coredump
Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

#include 
int main(int argc, void *argv) { abort(); }
I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module `compat_netbsd32', 
error 8
modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin

!DSPAM:5fa3f309175521945872603!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+





++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


re: CVS commit: src/sys

2020-11-07 Thread matthew green
>   .if ${MACHINE_ARCH} == "arm"

this is wrong.  it should use MACHINE_CPU.


.mrg.


Re: CVS commit: src/sys

2020-11-07 Thread Christos Zoulas
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7


christos

> On Nov 7, 2020, at 4:27 PM, Paul Goyette  wrote:
> 
> OK, I think I found the problem, but I don't know how to solve it...
> 
> All of the undefined symbols are supposed to be provided by
> 
>   .../sys/arch/arm/arm32/netbsd32_machdep.c
> 
> but there is no netbsd32_machdep.o included in the compat_netbsd32
> module.  This file should be included by the following code in 
> .../sys/modules/compat_netbsd32/Makefile
> 
>   .if ${MACHINE_ARCH} == "arm"
>   .PATH:  ${S}/arch/arm/arm32
>   SRCS+=  netbsd32_machdep.c
>   .endif
> 
> but it seems not to work (or at least, it doesn't do what it was
> intended to do).
> 
> 
> 
> 
> 
> 
> On Thu, 5 Nov 2020, Rin Okuyama wrote:
> 
>> On 2020/11/05 5:43, Paul Goyette wrote:
>>> BTW, the patch you submitted with the initial message in this thread
>>> looks good for avoiding the issue.  But I'm not sure it is a complete
>>> solution.
>>> In particular, you would need to build a 32-bit arm that contains ``no
>>> options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
>>> and compat_netbsd32_coredump modules
>>> 
>>> modload compat_netbsd32
>>> modload compat_netbsd32_coredump
>>> Then see if emulation of the old ABI still works, and check if core-
>>> dump works for old-ADI programs; the test program I've been using for
>>> core-dump checking is
>>> 
>>> #include 
>>> int main(int argc, void *argv) { abort(); }
>>> I really have to leave and take care of some personal business, so I
>>> would greatly appreciate if you can check this out.
>> 
>> Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:
>> 
>> 
>> # uname -ap
>> NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
>> rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
>> # modload compat_netbsd32
>> [  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_vm_default_addr' not found
>> [  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_machdep_md_init' not found
>> [  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_sendsig' not found
>> [  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `cpu_mcontext32_validate' not found
>> [  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `cpu_setmcontext32' not found
>> [  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_machdep_md_fini' not found
>> [  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `startlwp32' not found
>> [  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `cpu_getmcontext32' not found
>> [  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `machine32' not found
>> [  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
>> `netbsd32_sysarch' not found
>> [  29.7318320] WARNING: module error: unable to affix module 
>> `compat_netbsd32', error 8
>> modload: compat_netbsd32: Exec format error
>> 
>> 
>> This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
>> not included in compat_netbsd32 module. compat_netbsd32 module must not
>> work also for aarch64 and mips64 for the same reason, whereas amd64 and
>> sparc64 seem OK.
>> 
>> Thanks,
>> rin
>> 
>> !DSPAM:5fa3f309175521945872603!
>> 
>> 
> 
> ++--+---+
> | Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
> | (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
> ++--+---+



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys

2020-11-07 Thread Paul Goyette

OK, I think I found the problem, but I don't know how to solve it...

All of the undefined symbols are supposed to be provided by

.../sys/arch/arm/arm32/netbsd32_machdep.c

but there is no netbsd32_machdep.o included in the compat_netbsd32
module.  This file should be included by the following code in 
.../sys/modules/compat_netbsd32/Makefile


.if ${MACHINE_ARCH} == "arm"
.PATH:  ${S}/arch/arm/arm32
SRCS+=  netbsd32_machdep.c
.endif

but it seems not to work (or at least, it doesn't do what it was
intended to do).






On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.

In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

 modload compat_netbsd32
 modload compat_netbsd32_coredump

Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

 #include 
 int main(int argc, void *argv) { abort(); }

I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf

# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module 
`compat_netbsd32', error 8

modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin

!DSPAM:5fa3f309175521945872603!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys

2020-11-05 Thread Rin Okuyama

On 2020/11/05 23:07, Paul Goyette wrote:

I will investigate.


Thanks!


Can you confirm that it works correctly if you have the built-in
module?  (ie, kernel with ``options COMPAT_NETBSD32'')


Yes, it works fine.

rin


Re: CVS commit: src/sys

2020-11-05 Thread Paul Goyette

I will investigate.

Can you confirm that it works correctly if you have the built-in
module?  (ie, kernel with ``options COMPAT_NETBSD32'')


On Thu, 5 Nov 2020, Rin Okuyama wrote:


On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.

In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

 modload compat_netbsd32
 modload compat_netbsd32_coredump

Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

 #include 
 int main(int argc, void *argv) { abort(); }

I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020 
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf

# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module 
`compat_netbsd32', error 8

modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin

!DSPAM:5fa3f309175521945872603!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys

2020-11-05 Thread Rin Okuyama

On 2020/11/05 5:43, Paul Goyette wrote:

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.

In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

 modload compat_netbsd32
 modload compat_netbsd32_coredump

Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

 #include 
 int main(int argc, void *argv) { abort(); }

I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.


Hmm, ``modload compat_netbsd32'' does not work on evbarmv6hf-el:


# uname -ap
NetBSD  9.99.75 NetBSD 9.99.75 (RPI0) #11: Thu Nov  5 20:26:39 JST 2020  
rin@latipes:/sys/arch/evbarm/compile/RPI0 evbarm earmv6hf
# modload compat_netbsd32
[  29.6328410] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_vm_default_addr' not found
[  29.6460400] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_init' not found
[  29.6560750] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sendsig' not found
[  29.6661200] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_mcontext32_validate' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_setmcontext32' not found
[  29.6791570] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_machdep_md_fini' not found
[  29.6948370] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`startlwp32' not found
[  29.7048770] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`cpu_getmcontext32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`machine32' not found
[  29.7168550] kobj_checksyms, 994: [compat_netbsd32]: linker error: symbol 
`netbsd32_sysarch' not found
[  29.7318320] WARNING: module error: unable to affix module `compat_netbsd32', 
error 8
modload: compat_netbsd32: Exec format error


This should be because there are ``#ifdef COMPAT_NETBSD32'' codes in files
not included in compat_netbsd32 module. compat_netbsd32 module must not
work also for aarch64 and mips64 for the same reason, whereas amd64 and
sparc64 seem OK.

Thanks,
rin


Re: CVS commit: src/sys/kern

2020-11-05 Thread Rin Okuyama

On 2020/11/05 2:45, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


On 2020/11/04 22:52, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


Yes:

$ config -x netbsd.gdb | grep PTRACE
###> options    PTRACE  # Include ptrace(2) syscall
###> options    PTRACE_HOOKS    # Include ptrace hooks

The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():

https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184

   184 static int
   185 ptrace_modcmd(modcmd_t cmd, void *arg)
   186 {
   187 int error;
   188
   189 switch (cmd) {
   190 case MODULE_CMD_INIT:
   191 error = syscall_establish(_netbsd, ptrace_syscalls);
   192 break;
   193 case MODULE_CMD_FINI:
   194 error = syscall_disestablish(_netbsd, ptrace_syscalls);
   195 break;
   196 default:
   197 error = ENOTTY;
   198 break;
   199 }
   200 return error;
   201 }


Yes that would be a problem.


Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:

$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1]   Abort trap (core dumped) gdb echo

Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.


I have some prior obligations, so I won't be able to look at this
until this evening.

Thanks for the detailed analysis.


Fixed. Thanks!

rin


Re: CVS commit: src/sys

2020-11-04 Thread Paul Goyette

BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue.  But I'm not sure it is a complete
solution.

In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and compat_netbsd32_coredump modules

modload compat_netbsd32
modload compat_netbsd32_coredump

Then see if emulation of the old ABI still works, and check if core-
dump works for old-ADI programs; the test program I've been using for
core-dump checking is

#include 
int main(int argc, void *argv) { abort(); }

I really have to leave and take care of some personal business, so I
would greatly appreciate if you can check this out.

Thanks!



On Wed, 4 Nov 2020, Paul Goyette wrote:


I guess I don't understand why a 32-bit architecture would also have
COMPAT_NETBSD32.

Christos, can you help out on this?



On Wed, 4 Nov 2020, Rin Okuyama wrote:


Hello again,

On 2020/11/02 3:51, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Nov  1 18:51:03 UTC 2020

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile

Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.

Welcome to 7.99.75 !!!


To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h

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


This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:

	panic: kernel diagnostic assertion "!*hooked" failed: file 
"../../../../kern/kern_module_hook.c", line 70


Does the attached patch seem reasonable to you?

Thanks,
rin





++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

!DSPAM:5fa2ae10252946113815662!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/kern

2020-11-04 Thread Paul Goyette

OK, this is my mistake.  When I change the calls in the ptrace_common
modcmd, I should also have renamed the functions (including their
entries in sys/ptrace.h).  I will commit this shortly, before I leave.

Thanks for the "recipe" for reproducing the problem - I will try it 
later when I return.



On Wed, 4 Nov 2020, Rin Okuyama wrote:


On 2020/11/04 22:52, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


Yes:

$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE  # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks

The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():

https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184

   184 static int
   185 ptrace_modcmd(modcmd_t cmd, void *arg)
   186 {
   187  int error;
   188
   189  switch (cmd) {
   190  case MODULE_CMD_INIT:
   191 		error = syscall_establish(_netbsd, 
ptrace_syscalls);

   192  break;
   193  case MODULE_CMD_FINI:
   194 		error = syscall_disestablish(_netbsd, 
ptrace_syscalls);

   195  break;
   196  default:
   197  error = ENOTTY;
   198  break;
   199  }
   200  return error;
   201 }

Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:

$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 
'gdb_exception_RETURN_MASK_ERROR'

[1]   Abort trap (core dumped) gdb echo

Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.

Thanks,
rin

!DSPAM:5fa2b869233318156490363!




++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/kern

2020-11-04 Thread Paul Goyette

On Wed, 4 Nov 2020, Rin Okuyama wrote:


On 2020/11/04 22:52, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


Yes:

$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE  # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks

The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():

https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184

   184 static int
   185 ptrace_modcmd(modcmd_t cmd, void *arg)
   186 {
   187  int error;
   188
   189  switch (cmd) {
   190  case MODULE_CMD_INIT:
   191 		error = syscall_establish(_netbsd, 
ptrace_syscalls);

   192  break;
   193  case MODULE_CMD_FINI:
   194 		error = syscall_disestablish(_netbsd, 
ptrace_syscalls);

   195  break;
   196  default:
   197  error = ENOTTY;
   198  break;
   199  }
   200  return error;
   201 }


Yes that would be a problem.


Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:

$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 
'gdb_exception_RETURN_MASK_ERROR'

[1]   Abort trap (core dumped) gdb echo

Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.


I have some prior obligations, so I won't be able to look at this
until this evening.

Thanks for the detailed analysis.



++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/kern

2020-11-04 Thread Rin Okuyama

On 2020/11/04 22:52, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


Yes:

$ config -x netbsd.gdb | grep PTRACE
###> optionsPTRACE  # Include ptrace(2) syscall
###> optionsPTRACE_HOOKS# Include ptrace hooks

The problem is that ptrace_{init,fini}() are not called from
ptrace_modcmd():

https://nxr.netbsd.org/xref/src/sys/kern/sys_ptrace.c#184

184 static int
185 ptrace_modcmd(modcmd_t cmd, void *arg)
186 {
187 int error;
188
189 switch (cmd) {
190 case MODULE_CMD_INIT:
191 error = syscall_establish(_netbsd, 
ptrace_syscalls);
192 break;
193 case MODULE_CMD_FINI:
194 error = syscall_disestablish(_netbsd, 
ptrace_syscalls);
195 break;
196 default:
197 error = ENOTTY;
198 break;
199 }
200 return error;
201 }

Can you easily confirm that ktrace(2) is unusable for non-privileged
users on 9.99.75 kernel:

$ gdb echo
GNU gdb (GDB) 8.3
...
(gdb) b main
Breakpoint 1 at 0x950: file /usr/src/bin/echo/echo.c, line 58.
(gdb) r
Starting program: /bin/echo
warning: Could not trace the inferior process.
Error:
warning: ptrace: Operation not permitted
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
[1]   Abort trap (core dumped) gdb echo

Also, ptrace_{init,fini} should be moved from sys_ptrace_common.c to
sys_ptrace.c, IMO.

Thanks,
rin


Re: CVS commit: src/sys

2020-11-04 Thread Jason Thorpe



> On Nov 4, 2020, at 5:33 AM, Paul Goyette  wrote:
> 
> I guess I don't understand why a 32-bit architecture would also have
> COMPAT_NETBSD32.

In this particular case, it's for the old 32-bit ABI that predates the EABI 
standard the ARM port now uses.

-- thorpej



Re: CVS commit: src/sys/kern

2020-11-04 Thread Paul Goyette

On Wed, 4 Nov 2020, Rin Okuyama wrote:


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.


If the module is built-in (``options PTRACE'' selected in the config
file), then the module will already have been initialized.

If the module is not built-in, then a privileged user will need to
modload(8) the module.

Prior to this change, the built-in ptrace_common module was calling
the ptrace module's init/fini routine.  Quite likely ptrace_common
was built-in (due to inclusion of file-system PROCFS), so the init
was handled during init_main().  This change ensures that the ptrace
init/fini routines are called ONLY if the ptrace module itself (not
the ptrace_common) routine is built-in.

Please check to make sure that ``options PTRACE'' is included in
your kernel config.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: CVS commit: src/sys/kern

2020-11-04 Thread Rin Okuyama

On 2020/11/04 22:31, Paul Goyette wrote:

On Wed, 4 Nov 2020, Rin Okuyama wrote:


Hi,

On 2020/10/26 0:55, Paul Goyette wrote:

Module Name:    src
Committed By:    pgoyette
Date:    Sun Oct 25 15:55:37 UTC 2020

Modified Files:
src/sys/kern: sys_ptrace_common.c

Log Message:
ptrace_Common is a module unto itself.  Don't use the ptrace module's
init/fini routines.


To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c

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


This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


Oops, sorry, I meant ptrace_{init,fini}(). These functions are not called
at all since this commit, which forbids ptrace(2) for non-root users.

Thanks,
rin


Re: CVS commit: src/sys

2020-11-04 Thread Martin Husemann
On Wed, Nov 04, 2020 at 05:33:29AM -0800, Paul Goyette wrote:
> I guess I don't understand why a 32-bit architecture would also have
> COMPAT_NETBSD32.

(At least) mips and arm have various 32bit ABIs that are handled by
COMPAT_NETBSD32.

Martin


Re: CVS commit: src/sys

2020-11-04 Thread Paul Goyette

I guess I don't understand why a 32-bit architecture would also have
COMPAT_NETBSD32.

Christos, can you help out on this?



On Wed, 4 Nov 2020, Rin Okuyama wrote:


Hello again,

On 2020/11/02 3:51, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Nov  1 18:51:03 UTC 2020

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile

Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.

Welcome to 7.99.75 !!!


To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h

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


This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:

	panic: kernel diagnostic assertion "!*hooked" failed: file 
"../../../../kern/kern_module_hook.c", line 70


Does the attached patch seem reasonable to you?

Thanks,
rin


!DSPAM:5fa25cf9259143308188765!


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys/kern

2020-11-04 Thread Paul Goyette

On Wed, 4 Nov 2020, Rin Okuyama wrote:


Hi,

On 2020/10/26 0:55, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Oct 25 15:55:37 UTC 2020

Modified Files:
src/sys/kern: sys_ptrace_common.c

Log Message:
ptrace_Common is a module unto itself.  Don't use the ptrace module's
init/fini routines.


To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c

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


This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.


ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c.  The modcmd routine in
turn is called at module initialization time.  In the case of a
built-in module, it will be called by module_init via init_main; if
the module is loaded (or auto-loaded) module_load will call the
modcmd routine.

The module will be built-in if either ``options PTRACE'' or ``file-
system PROCFS'' is set in the kernel configuration file.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/sys

2020-11-03 Thread Rin Okuyama

Hello again,

On 2020/11/02 3:51, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Nov  1 18:51:03 UTC 2020

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile

Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.

Welcome to 7.99.75 !!!


To generate a diff of this commit:
cvs rdiff -u -r1.133 -r1.134 src/sys/compat/netbsd32/netbsd32.h
cvs rdiff -u -r1.15 -r1.16 src/sys/compat/netbsd32/netbsd32_core.c
cvs rdiff -u -r1.20 -r1.21 src/sys/kern/compat_stub.c
cvs rdiff -u -r1.53 -r1.54 src/sys/kern/files.kern
cvs rdiff -u -r1.33 -r1.34 src/sys/kern/kern_core.c
cvs rdiff -u -r1.394 -r1.395 src/sys/kern/kern_sig.c
cvs rdiff -u -r1.88 -r1.89 src/sys/kern/sys_ptrace_common.c
cvs rdiff -u -r1.247 -r1.248 src/sys/modules/Makefile
cvs rdiff -u -r1.35 -r1.36 src/sys/modules/compat_netbsd32/Makefile
cvs rdiff -u -r0 -r1.1 src/sys/modules/compat_netbsd32_coredump/Makefile
cvs rdiff -u -r1.7 -r1.8 src/sys/modules/coredump/Makefile
cvs rdiff -u -r1.24 -r1.25 src/sys/sys/compat_stub.h
cvs rdiff -u -r1.677 -r1.678 src/sys/sys/param.h
cvs rdiff -u -r1.102 -r1.103 src/sys/sys/signalvar.h

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


This commit breaks arm, i.e., ILP32 arch with COMPAT_NETBSD32. For arm,
coredump_elf32_hook is already hooked in the main kernel. Therefore,
compat_netbsd32_coredump_modcmd(MODULE_CMD_INIT) causes KASSERT failure:

panic: kernel diagnostic assertion "!*hooked" failed: file 
"../../../../kern/kern_module_hook.c", line 70

Does the attached patch seem reasonable to you?

Thanks,
rin
Index: sys/compat/netbsd32/netbsd32_core.c
===
RCS file: /home/netbsd/src/sys/compat/netbsd32/netbsd32_core.c,v
retrieving revision 1.16
diff -p -u -r1.16 netbsd32_core.c
--- sys/compat/netbsd32/netbsd32_core.c 1 Nov 2020 18:51:02 -   1.16
+++ sys/compat/netbsd32/netbsd32_core.c 4 Nov 2020 06:52:52 -
@@ -68,11 +68,15 @@ compat_netbsd32_coredump_modcmd(modcmd_t
switch (cmd) {
case MODULE_CMD_INIT:
MODULE_HOOK_SET(coredump_netbsd32_hook, real_coredump_netbsd32);
+#ifdef _LP64
MODULE_HOOK_SET(coredump_elf32_hook, real_coredump_elf32);
+#endif
return 0;
case MODULE_CMD_FINI:
MODULE_HOOK_UNSET(coredump_netbsd32_hook);
+#ifdef _LP64
MODULE_HOOK_UNSET(coredump_elf32_hook);
+#endif
return 0;
default:
return ENOTTY;


Re: CVS commit: src/sys/kern

2020-11-03 Thread Rin Okuyama

Hi,

On 2020/10/26 0:55, Paul Goyette wrote:

Module Name:src
Committed By:   pgoyette
Date:   Sun Oct 25 15:55:37 UTC 2020

Modified Files:
src/sys/kern: sys_ptrace_common.c

Log Message:
ptrace_Common is a module unto itself.  Don't use the ptrace module's
init/fini routines.


To generate a diff of this commit:
cvs rdiff -u -r1.87 -r1.88 src/sys/kern/sys_ptrace_common.c

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


This commit makes ptrace(2) unusable for non-privileged users;
ptrace_common_{init,fini}() should be called from somewhere.

Thanks,
rin


Re: CVS commit: src/sys

2020-11-01 Thread Paul Goyette

On Sun, 1 Nov 2020, Paul Goyette wrote:


Module Name:src
Committed By:   pgoyette
Date:   Sun Nov  1 18:51:03 UTC 2020

Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
sys_ptrace_common.c
src/sys/modules: Makefile
src/sys/modules/compat_netbsd32: Makefile
src/sys/modules/coredump: Makefile
src/sys/sys: compat_stub.h param.h signalvar.h
Added Files:
src/sys/modules/compat_netbsd32_coredump: Makefile

Log Message:
Separate the compat_netbsd32_coredump from the compat_netbsd32 and
coredump modules, into its own module.

Welcome to 7.99.75 !!!


Of course, this should be "Welcome to 9.99.75"

:)

++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/external/bsd/tmux

2020-11-01 Thread Christos Zoulas
I've asked.

Best,

christos

> On Nov 1, 2020, at 11:19 AM, Kimmo Suominen  wrote:
> 
>> Log Message:
>> CHANGED FROM 3.1b TO 3.1c
>> 
>> * Do not write after the end of the array and overwrite the stack when
>>  colon-separated SGR sequences contain empty arguments.
> 
> Pullup to -9 and -8 for security fix?
> 
> https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/external/bsd/tmux

2020-11-01 Thread Kimmo Suominen
> Log Message:
> CHANGED FROM 3.1b TO 3.1c
> 
> * Do not write after the end of the array and overwrite the stack when
>   colon-separated SGR sequences contain empty arguments.

Pullup to -9 and -8 for security fix?

https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html



Re: CVS commit: src

2020-10-28 Thread David H. Gutteridge
On Wed, 2020-10-28 at 11:56 +, nia wrote:
> On Tue, Oct 27, 2020 at 05:01:51PM -0400, David H. Gutteridge wrote:
> > > i can have a look at mate-applets tomorrow, the current code looks
> > > like it won't work with AMD CPUs on netbsd-9 and that should
> > > ideally
> > > be fixed.
> > 
> > Yeah, that's my understanding. (I'm guessing Youri only had Intel
> > hardware to test with, which was also true for me until recently.
> 
> i actually can't get the mate-applets cpufreq thing to work at all,
> it keeps thinking my CPU is running at 2 MHz. was it working for
> you before the change?

I just tried it with 9.99.72 from September (on an Intel i5-3340M), and
I get the same bogus "2 MHz" value reported. I'd thought it had worked
at some point in the past, but maybe I'm misremembering. (I don't
normally use mate-applets myself; I only test it if I'm updating MATE
packages to a new version. I'd remembered the code in question from
looking through it some time ago.)

Dave




Re: CVS commit: src

2020-10-28 Thread nia
On Tue, Oct 27, 2020 at 05:01:51PM -0400, David H. Gutteridge wrote:
> > i can have a look at mate-applets tomorrow, the current code looks
> > like it won't work with AMD CPUs on netbsd-9 and that should ideally
> > be fixed.
> 
> Yeah, that's my understanding. (I'm guessing Youri only had Intel
> hardware to test with, which was also true for me until recently.

i actually can't get the mate-applets cpufreq thing to work at all,
it keeps thinking my CPU is running at 2 MHz. was it working for
you before the change?


Re: CVS commit: src

2020-10-27 Thread David H. Gutteridge
On Tue, 2020-10-27 at 19:54 +, nia wrote:
> On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote:
> > On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
> > > On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> > > > this doesn't seem like the right design.  we have cpus
> > > > already that have multiple frequency domains, so this
> > > > doesn't work with that setup, so attempt to use it as a
> > > > general method for estd etc seems limited and thsu not
> > > > the right method.
> > > > 
> > > > eg, rk3399 systems have .cpu0 and .cpu4 domains for the
> > > > 4 slow and 2 fast cores it has, and they have both
> > > > separate controls as well as list of available freqs:
> > > > 
> > > > machdep.cpufreq.cpu0.target = 1416
> > > > machdep.cpufreq.cpu0.current = 1416
> > > > machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
> > > > machdep.cpufreq.cpu4.target = 1800
> > > > machdep.cpufreq.cpu4.current = 1800
> > > > machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816
> > > > 600 408
> > > > 
> > > 
> > > yeah, i'm aware of this, my intent was really only to normalize
> > > the variables that didn't have multi-cpu-domain support (since
> > > those are already normalized as rk3399)
> > > 
> > > do you think we should use the same variable and tie things to
> > > under cpu0 when there isn't support for scaling independent CPUs?
> > > 
> > > > additionally, if we are going to design a "good" API for
> > > > this, it should publish things outside of "machdep".
> > > > i'd go with hw.cpufreq probbaly.
> > > > 
> > > > (i didn't look, but it sure would be annoying if the old
> > > > nodes that have existed for over a decade were changed
> > > > and any other 3rd party code or scrip tis now broken.)
> > > 
> > > i actually picked this name because it was already in use and
> > > thus already checked by estd.
> > > 
> > > i agree it should go outside machdep, but i didn't want
> > > to break existing code.
> > 
> > This has impacted youri@'s NetBSD frequency handling patches in x11/
> > mate-applets, which only make references using
> > "machdep.est.frequency"
> > at present.
> > 
> > Since this change removes pre-existing sysctl nodes, shouldn't this
> > merit a kernel version bump? It potentially breaks things in user-
> > space. (I see from the mailing list archives that Mouse asked about
> > the idea of retaining old names for compatibility.)
> > 
> > (Now, the mate-applets situation could be improved by the new,
> > generic
> > means of exposing this information. martin@ had asked for non-x86
> > support in PR pkg/53975, one of the barriers being I imagine few
> > people
> > have the hardware to test with. I don't.)
> > 
> > Dave
> > 
> > 
> 
> i can have a look at mate-applets tomorrow, the current code looks
> like it won't work with AMD CPUs on netbsd-9 and that should ideally
> be fixed.

Yeah, that's my understanding. (I'm guessing Youri only had Intel
hardware to test with, which was also true for me until recently.)

> i thought kernel versions were specifically about module
> compatibility.

That may be the case, that was a question for any kernel developers at
large. :)

Dave




Re: CVS commit: src

2020-10-27 Thread nia
On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote:
> On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
> >On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> >> this doesn't seem like the right design.  we have cpus
> >> already that have multiple frequency domains, so this
> >> doesn't work with that setup, so attempt to use it as a
> >> general method for estd etc seems limited and thsu not
> >> the right method.
> >> 
> >> eg, rk3399 systems have .cpu0 and .cpu4 domains for the
> >> 4 slow and 2 fast cores it has, and they have both
> >> separate controls as well as list of available freqs:
> >> 
> >> machdep.cpufreq.cpu0.target = 1416
> >> machdep.cpufreq.cpu0.current = 1416
> >> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
> >> machdep.cpufreq.cpu4.target = 1800
> >> machdep.cpufreq.cpu4.current = 1800
> >> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408
> >>
> >
> >yeah, i'm aware of this, my intent was really only to normalize
> >the variables that didn't have multi-cpu-domain support (since
> >those are already normalized as rk3399)
> >
> >do you think we should use the same variable and tie things to
> >under cpu0 when there isn't support for scaling independent CPUs?
> >
> >> additionally, if we are going to design a "good" API for
> >> this, it should publish things outside of "machdep".
> >> i'd go with hw.cpufreq probbaly.
> >> 
> >> (i didn't look, but it sure would be annoying if the old
> >> nodes that have existed for over a decade were changed
> >> and any other 3rd party code or scrip tis now broken.)
> >
> >i actually picked this name because it was already in use and
> >thus already checked by estd.
> >
> >i agree it should go outside machdep, but i didn't want
> >to break existing code.
> 
> This has impacted youri@'s NetBSD frequency handling patches in x11/
> mate-applets, which only make references using "machdep.est.frequency"
> at present.
> 
> Since this change removes pre-existing sysctl nodes, shouldn't this
> merit a kernel version bump? It potentially breaks things in user-
> space. (I see from the mailing list archives that Mouse asked about
> the idea of retaining old names for compatibility.)
> 
> (Now, the mate-applets situation could be improved by the new, generic
> means of exposing this information. martin@ had asked for non-x86
> support in PR pkg/53975, one of the barriers being I imagine few people
> have the hardware to test with. I don't.)
> 
> Dave
> 
>

i can have a look at mate-applets tomorrow, the current code looks
like it won't work with AMD CPUs on netbsd-9 and that should ideally
be fixed.

i thought kernel versions were specifically about module compatibility.


Re: CVS commit: src

2020-10-27 Thread David H. Gutteridge
On Tue, 27 Oct 2020 at 09:04:28 +, nia wrote:
>On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
>> this doesn't seem like the right design.  we have cpus
>> already that have multiple frequency domains, so this
>> doesn't work with that setup, so attempt to use it as a
>> general method for estd etc seems limited and thsu not
>> the right method.
>> 
>> eg, rk3399 systems have .cpu0 and .cpu4 domains for the
>> 4 slow and 2 fast cores it has, and they have both
>> separate controls as well as list of available freqs:
>> 
>> machdep.cpufreq.cpu0.target = 1416
>> machdep.cpufreq.cpu0.current = 1416
>> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
>> machdep.cpufreq.cpu4.target = 1800
>> machdep.cpufreq.cpu4.current = 1800
>> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408
>>
>
>yeah, i'm aware of this, my intent was really only to normalize
>the variables that didn't have multi-cpu-domain support (since
>those are already normalized as rk3399)
>
>do you think we should use the same variable and tie things to
>under cpu0 when there isn't support for scaling independent CPUs?
>
>> additionally, if we are going to design a "good" API for
>> this, it should publish things outside of "machdep".
>> i'd go with hw.cpufreq probbaly.
>> 
>> (i didn't look, but it sure would be annoying if the old
>> nodes that have existed for over a decade were changed
>> and any other 3rd party code or scrip tis now broken.)
>
>i actually picked this name because it was already in use and
>thus already checked by estd.
>
>i agree it should go outside machdep, but i didn't want
>to break existing code.

This has impacted youri@'s NetBSD frequency handling patches in x11/
mate-applets, which only make references using "machdep.est.frequency"
at present.

Since this change removes pre-existing sysctl nodes, shouldn't this
merit a kernel version bump? It potentially breaks things in user-
space. (I see from the mailing list archives that Mouse asked about
the idea of retaining old names for compatibility.)

(Now, the mate-applets situation could be improved by the new, generic
means of exposing this information. martin@ had asked for non-x86
support in PR pkg/53975, one of the barriers being I imagine few people
have the hardware to test with. I don't.)

Dave




Re: CVS commit: src

2020-10-27 Thread nia
On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> this doesn't seem like the right design.  we have cpus
> already that have multiple frequency domains, so this
> doesn't work with that setup, so attempt to use it as a
> general method for estd etc seems limited and thsu not
> the right method.
> 
> eg, rk3399 systems have .cpu0 and .cpu4 domains for the
> 4 slow and 2 fast cores it has, and they have both
> separate controls as well as list of available freqs:
> 
> machdep.cpufreq.cpu0.target = 1416
> machdep.cpufreq.cpu0.current = 1416
> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
> machdep.cpufreq.cpu4.target = 1800
> machdep.cpufreq.cpu4.current = 1800
> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408
>

yeah, i'm aware of this, my intent was really only to normalize
the variables that didn't have multi-cpu-domain support (since
those are already normalized as rk3399)

do you think we should use the same variable and tie things to
under cpu0 when there isn't support for scaling independent CPUs?

> additionally, if we are going to design a "good" API for
> this, it should publish things outside of "machdep".
> i'd go with hw.cpufreq probbaly.
> 
> (i didn't look, but it sure would be annoying if the old
> nodes that have existed for over a decade were changed
> and any other 3rd party code or scrip tis now broken.)

i actually picked this name because it was already in use and
thus already checked by estd.

i agree it should go outside machdep, but i didn't want
to break existing code.


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

2020-10-26 Thread David Holland
On Sun, Oct 25, 2020 at 05:37:36PM +, Simon J. Gerraty wrote:
 > Modified Files:
 >  src/usr.bin/make: main.c
 >  src/usr.bin/make/unit-tests: varmod-match-escape.exp
 > 
 > Log Message:
 > Skip reading .MAKE.DEPENDFILE if set to
 > "/dev/null" or anything starting with "no".
 > 
 > Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223564

I object to this, particularly the "no" part but also making /dev/null
magic.

This is an unnecessary workaround for a bug in freebsd's build
system.

If there's going to be a change, it should be removing the :T from the
generated reference; there is no reason to remove the directory name
from a user-supplied .MAKE.DEPENDFILE, and the default doesn't have a
directory part. That would also remove the problem freebsd's seeing,
and would be, y'know, actually correct.

(also the application of :T is undocumented as well as wrong)


kept for reference:

 > To generate a diff of this commit:
 > cvs rdiff -u -r1.388 -r1.389 src/usr.bin/make/main.c
 > cvs rdiff -u -r1.1 -r1.2 src/usr.bin/make/unit-tests/varmod-match-escape.exp

-- 
David A. Holland
dholl...@netbsd.org


re: CVS commit: src

2020-10-26 Thread matthew green
"Nia Alarie" writes:
> Module Name:  src
> Committed By: nia
> Date: Sun Oct 25 16:39:00 UTC 2020
>
> Modified Files:
>   src/share/man/man4: acpicpu.4
>   src/share/man/man4/man4.x86: est.4 powernow.4
>   src/sys/arch/evbmips/loongson: loongson_clock.c
>   src/sys/arch/macppc/dev: obio.c
>   src/sys/arch/x86/acpi: acpi_cpu_md.c
>   src/sys/arch/x86/x86: est.c powernow.c
>
> Log Message:
> Normalize some machine dependent CPU frequenct sysctl variables.
>
> This moves machdep.*.frequency.* to machdep.cpu.frequency.*.
>
> This was proposed on tech-kern some time ago. The intention is to allow
> third-party tools such as estd and conky to more easily and reliably
> fetch or modify the current CPU frequency without iterating through
> various machine-dependent variables to check their presence.

sorry, i must have missed your tech-kern post.

this doesn't seem like the right design.  we have cpus
already that have multiple frequency domains, so this
doesn't work with that setup, so attempt to use it as a
general method for estd etc seems limited and thsu not
the right method.

eg, rk3399 systems have .cpu0 and .cpu4 domains for the
4 slow and 2 fast cores it has, and they have both
separate controls as well as list of available freqs:

machdep.cpufreq.cpu0.target = 1416
machdep.cpufreq.cpu0.current = 1416
machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
machdep.cpufreq.cpu4.target = 1800
machdep.cpufreq.cpu4.current = 1800
machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408


additionally, if we are going to design a "good" API for
this, it should publish things outside of "machdep".
i'd go with hw.cpufreq probbaly.


.mrg.

(i didn't look, but it sure would be annoying if the old
nodes that have existed for over a decade were changed
and any other 3rd party code or scrip tis now broken.)


Re: CVS commit: src/sbin/mount

2020-10-25 Thread nia
On Sat, Oct 24, 2020 at 10:38:04PM +0700, Robert Elz wrote:
>   | file systems that are used as what spools?
> 
> Ah, youth!
> 
> The old text:
>   This option is useful for optimizing read performance on file systems
>   that are used as news spools.
> was refering to netnews (usenet, NNTP or whatever).

Don't worry, I know about usenet. I just think it's a particularly
obscure use case today, even for netbsd!

> Such a filesystem is almost certainly not going to care about access times
> (this is about uses for the noatime flag, to save others needing to go look
> at what changed) as the news articles are referenced by large numbers of
> news readers, and outgoing feeds, and when any of that happened is of no
> interest to the server or its maintainers, at all - but it happens (or
> happened, when usenet was a big thing) a lot, and not bothering to update
> the access times could mean a lot of unnecessary writes to an already very
> busy filesystem.
> 
> All that said, note that I am not objecting to the change (referring to
> flash based filesystems rather than news spools) it is a little more
> currently relevant.
> 
> kre

Thanks for the background information.


Re: CVS commit: src/sbin/mount

2020-10-24 Thread David Holland
On Sat, Oct 24, 2020 at 10:51:34AM +, Nia Alarie wrote:
 > Modified Files:
 >  src/sbin/mount: mount.8
 > 
 > Log Message:
 > file systems that are used as what spools?

Kibozing caches.

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/sys/arch/sparc64/dev

2020-10-24 Thread Julian Coleman
Hi Tobias,

> If you're interested there is an older version[1] of envctrl in the
> Attic that might be relevant to use for reference. It supported fan
> speed controls on E450. IIRC I got some of the magic constants from
> OpenSolaris. Sadly I don't own an E450 any more.
> 
> [1] 
> cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/sparc64/dev/Attic/envctrl.c?rev=1.11=text/plain_with_tag=MAIN

Thank you - that's useful information!

Related to the magic offsets, I noticed that the value read from the sensor
was always lower than the value written.  However, it doesn't appear to be
a constant difference (I see about 15 for most values, but only 5 for the
minimum).  I think that it's OK to keep the higher value - it'll mean that
we run the fans slightly faster.  The CPU temperature on my E250 doesn't
reach the minimum threshold where the fan speed actually increases, so I
don't think that this will have any impact.

The GPIO values there helps to see what values I should be checking for too.

It would be good to merge this with the current code, but I only have an
E250 to test on, so I'll need to find a volunteer.

Regards,

Julian


Re: CVS commit: src/sys/arch/sparc64/dev

2020-10-24 Thread Tobias Nygren
On Sat, 24 Oct 2020 15:16:39 +
Julian Coleman  wrote:

> Module Name:  src
> Committed By: jdc
> Date: Sat Oct 24 15:16:39 UTC 2020
> 
> Modified Files:
>   src/sys/arch/sparc64/dev: pcf8591_envctrl.c
> 
> Log Message:
> Add support for automatically changing the CPU fan speed on the E250 in a
> similar way to the SB1000/SB2000.
> The fan control information was determined by experiment, as it's only
> partially available in OFW.
> Hardcode the missing information for E250 fan control into the driver
> (it should be possible to support the E450 in future too).

If you're interested there is an older version[1] of envctrl in the
Attic that might be relevant to use for reference. It supported fan
speed controls on E450. IIRC I got some of the magic constants from
OpenSolaris. Sadly I don't own an E450 any more.

[1] 
cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/sparc64/dev/Attic/envctrl.c?rev=1.11=text/plain_with_tag=MAIN


  1   2   3   4   5   6   7   8   9   10   >