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

2021-01-26 Thread Martin Husemann
On Tue, Jan 26, 2021 at 11:39:52PM +0100, Roland Illig wrote: > The code of usr.bin/make gets distributed to a wider audience by Simon's > bmake distribution (http://www.crufty.net/help/sjg/bmake.html), that's > where the requirement of supporting C89 compilers comes from. At the > time I

Re: CVS commit: src/sys/sys

2021-01-26 Thread Jason Thorpe
> On Jan 26, 2021, at 6:49 PM, Valery Ushakov wrote: > > It's hardly fair to characterize three people politely inquiring about > that choice and pointing out a more standard way to spell what you > want to express (that is perfectly in rhyme with the preceding table > and is only one

Re: CVS commit: src/sys/sys

2021-01-26 Thread Valery Ushakov
On Wed, Jan 27, 2021 at 01:00:05 +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Wed Jan 27 01:00:05 UTC 2021 > > Modified Files: > src/sys/sys: device.h > > Log Message: > Define a macro to terminate the common usage of device_compatible_entry >

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

2021-01-26 Thread Roland Illig
On 26.01.2021 21:04, Christos Zoulas wrote: Yes, and I did not push for it for the exact reasons stated below: There was only a handful of cases and those can be handled with casts or a macro for now. I am questioning though the utility of maintaining compatibility with platforms that do not

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

2021-01-26 Thread Christos Zoulas
Yes, and I did not push for it for the exact reasons stated below: There was only a handful of cases and those can be handled with casts or a macro for now. I am questioning though the utility of maintaining compatibility with platforms that do not support C99 20 years later, vs. using %u and

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

2021-01-26 Thread Roland Illig
On 26.01.2021 11:19, Rin Okuyama wrote: Ping? I don't think this is correct fix either. Can you please revert this commit? Sorry, I didn't get the first mail from Christos back in December, that's why I didn't take any action. Why shouldn't the fix I did be correct? I carefully checked the

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

2021-01-26 Thread Reinoud Zandijk
On Tue, Jan 26, 2021 at 05:51:42PM +0900, Rin Okuyama wrote: > Hi, > This seems not correct for me. Is the attached patch OK with you? Well you spotted a bug indeed int he freeing section. I'll fix and commit it. Thanks for reporting. Reinoud signature.asc Description: PGP signature

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

2021-01-26 Thread Rin Okuyama
Ping? I don't think this is correct fix either. Can you please revert this commit? Thanks, rin On 2020/12/15 7:57, Christos Zoulas wrote: In article <20201213212746.3cfc3f...@cvs.netbsd.org>, Roland Illig wrote: -=-=-=-=-=- Module Name:src Committed By: rillig Date: Sun Dec

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

2021-01-26 Thread Rin Okuyama
Hi, On 2021/01/25 0:33, Reinoud Zandijk wrote: Module Name:src Committed By: reinoud Date: Sun Jan 24 15:33:02 UTC 2021 Modified Files: src/sys/dev/pci: virtio_pci.c Log Message: On error unmap the pci_mapreg_map()d regions using bus_space_unmap() as suggested by jak@

Re: CVS commit: src/sys/arch

2021-01-25 Thread Jason Thorpe
> On Jan 25, 2021, at 9:45 AM, Robert Elz wrote: > >Date:Mon, 25 Jan 2021 08:19:44 -0800 >From:Jason Thorpe >Message-ID: > > | Using { 0 } makes an assumption about the first member of the > | structure which is not guaranteed to remain true. > > That's

Re: CVS commit: src/sys/arch

2021-01-25 Thread Kamil Rytarowski
On 25.01.2021 17:19, Jason Thorpe wrote: > >> On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote: >> >> I have no problem with this change but I am curious why should we use "{ >> }"? It's a C GNU extension and C++ syntax. > > Using { 0 } makes an assumption about the first member of the

Re: CVS commit: src/sys/arch

2021-01-25 Thread Valery Ushakov
On Mon, Jan 25, 2021 at 20:28:52 +0300, Valery Ushakov wrote: > On Mon, Jan 25, 2021 at 08:19:44 -0800, Jason Thorpe wrote: > > > > On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote: > > > > > > I have no problem with this change but I am curious why should we use "{ > > > }"? It's a C GNU

Re: CVS commit: src/sys/arch

2021-01-25 Thread Robert Elz
Date:Mon, 25 Jan 2021 08:19:44 -0800 From:Jason Thorpe Message-ID: | Using { 0 } makes an assumption about the first member of the | structure which is not guaranteed to remain true. That's right, but you could explicitly init a named field, most likely the one

Re: CVS commit: src/sys/arch

2021-01-25 Thread Valery Ushakov
On Mon, Jan 25, 2021 at 08:19:44 -0800, Jason Thorpe wrote: > > On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote: > > > > I have no problem with this change but I am curious why should we use "{ > > }"? It's a C GNU extension and C++ syntax. > > Using { 0 } makes an assumption about the

Re: CVS commit: src/sys/arch

2021-01-25 Thread Jason Thorpe
> On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote: > > I have no problem with this change but I am curious why should we use "{ > }"? It's a C GNU extension and C++ syntax. Using { 0 } makes an assumption about the first member of the structure which is not guaranteed to remain true. --

Re: CVS commit: src/sys/arch

2021-01-25 Thread Kamil Rytarowski
On 25.01.2021 15:20, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Mon Jan 25 14:20:39 UTC 2021 > > Modified Files: > src/sys/arch/arm/altera: cycv_clkmgr.c > src/sys/arch/arm/amlogic: meson_pinctrl.c meson_pwm.c meson_thermal.c >

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

2021-01-25 Thread Jason Thorpe
> On Jan 24, 2021, at 10:20 PM, Martin Husemann wrote: > >> I kept getting a ?static after non-static declaration? error when building >> for aarch64. > > I guess that was with outdated arm/include/bus_funcs.h and > sys/bus_proto.h (or where was the previous declaration)? I did a “cvs

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

2021-01-24 Thread Martin Husemann
On Sun, Jan 24, 2021 at 09:45:14PM -0800, Jason Thorpe wrote: > > > On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote: > > > > While I don't care for names, I would like to understand fallout in > > details before hiding it - what exactly did not compile correctly? > > At least the affected

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

2021-01-24 Thread Jason Thorpe
> On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote: > > While I don't care for names, I would like to understand fallout in > details before hiding it - what exactly did not compile correctly? > At least the affected arm kernels worked for me in the state directly > before your commit. I

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

2021-01-24 Thread Martin Husemann
On Sun, Jan 24, 2021 at 03:34:08PM +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Sun Jan 24 15:34:08 UTC 2021 > > Modified Files: > src/sys/dev/pci: virtio_pci.c > > Log Message: > Redefining bus_space functions in drivers is a bad idea, and we

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

2021-01-23 Thread Jason Thorpe
> On Jan 23, 2021, at 5:40 PM, Christos Zoulas wrote: > >> it's a bad example. someone might copy it into another >> driver that _doesn't_ work with this version, but may seem >> to fix a build error. >> >> that's why i wanted to wrap the usage to make it clear if >> someone were to copy it

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

2021-01-23 Thread Christos Zoulas
In article <17141.1611452...@splode.eterna.com.au>, matthew green wrote: >Christos Zoulas writes: >> In article <20210123230600.52be160...@jupiter.mumble.net>, >> Taylor R Campbell wrote: >> > >> >Conversely, how do you know whether this hacked-up implementation >> >which tears the write into

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

2021-01-23 Thread matthew green
Christos Zoulas writes: > In article <20210123230600.52be160...@jupiter.mumble.net>, > Taylor R Campbell wrote: > > > >Conversely, how do you know whether this hacked-up implementation > >which tears the write into two will actually work? Maybe it works for > >virtio but there are likely other

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

2021-01-23 Thread Christos Zoulas
In article <20210123230600.52be160...@jupiter.mumble.net>, Taylor R Campbell wrote: > >Conversely, how do you know whether this hacked-up implementation >which tears the write into two will actually work? Maybe it works for >virtio but there are likely other devices out there for which it will

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

2021-01-23 Thread Taylor R Campbell
> Date: Sat, 23 Jan 2021 22:59:22 - (UTC) > From: chris...@astron.com (Christos Zoulas) > > In article <23974.1611441...@splode.eterna.com.au>, > matthew green wrote: > >this seems dangerous to me. we don't define it on > >some platforms because we can't, so having it faked > >out here

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

2021-01-23 Thread Christos Zoulas
In article <23974.1611441...@splode.eterna.com.au>, matthew green wrote: >"Christos Zoulas" writes: >> Module Name: src >> Committed By:christos >> Date:Sat Jan 23 20:00:19 UTC 2021 >> >> Modified Files: >> src/sys/dev/pci: virtio_pci.c >> >> Log Message: >> Provide

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

2021-01-23 Thread matthew green
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Sat Jan 23 20:00:19 UTC 2021 > > Modified Files: > src/sys/dev/pci: virtio_pci.c > > Log Message: > Provide a generic bus_space_write_8 function that is bi-endian. this seems dangerous to me. we don't

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

2021-01-23 Thread Christos Zoulas
In article , Reinoud Zandijk wrote: >On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote: >> > +#ifndef _LP64 >> >> _LP64 is a terrible way to make this choice. >> >> heaps of our 32 bit platforms implement the _8 variants. > >Can't we then just make sure they have the 8 bit variant?

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

2021-01-23 Thread Christos Zoulas
In article , Nick Hudson wrote: >On 22/01/2021 04:48, Christos Zoulas wrote: >> +#if _QUAD_HIGHWORD >> +bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x)); >> +bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32)); >> +#else >> +bus_space_write_4(iot, ioh,

Re: CVS commit: src/sys/kern (kern_event.c)

2021-01-22 Thread Paul Goyette
On Fri, 22 Jan 2021, Paul Goyette wrote: On Thu, 21 Jan 2021, Paul Goyette wrote: Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. OK, I built and installed a new kernel+userland. Most everything works, and syslogd seems to work fine (at least,

Re: CVS commit: src/sys/kern (kern_event.c)

2021-01-22 Thread Paul Goyette
On Thu, 21 Jan 2021, Paul Goyette wrote: Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. OK, I built and installed a new kernel+userland. Most everything works, and syslogd seems to work fine (at least, it no longer panics during startup).

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

2021-01-22 Thread Reinoud Zandijk
On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote: > > +#ifndef _LP64 > > _LP64 is a terrible way to make this choice. > > heaps of our 32 bit platforms implement the _8 variants. Can't we then just make sure they have the 8 bit variant? and set a define if its atomic or not? This

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

2021-01-22 Thread Jared McNeill
I forgot that I added dma-ranges support back in Feb last year. All good, please ignore me :) On Thu, 21 Jan 2021, Jared McNeill wrote: This driver is not 64-bit safe and should not be enabled on aarch64 as-is. I think before turning it on we should restrict it to the lower 1GB of memory

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

2021-01-22 Thread Nick Hudson
On 22/01/2021 04:48, Christos Zoulas wrote: +#if _QUAD_HIGHWORD + bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x)); + bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32)); +#else + bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32)); +

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

2021-01-21 Thread Christos Zoulas
In article <27744.1611294...@splode.eterna.com.au>, matthew green wrote: >> +#ifndef _LP64 > >_LP64 is a terrible way to make this choice. > >heaps of our 32 bit platforms implement the _8 variants. Let's add a _HAVE_ variable then? christos

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

2021-01-21 Thread matthew green
> +#ifndef _LP64 _LP64 is a terrible way to make this choice. heaps of our 32 bit platforms implement the _8 variants. .mrg.

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

2021-01-21 Thread Christos Zoulas
In article <20210121204833.9ebcff...@cvs.netbsd.org>, Reinoud Zandijk wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: reinoud >Date: Thu Jan 21 20:48:33 UTC 2021 > >Modified Files: > src/sys/dev/pci: virtio_pci.c > >Log Message: >Remove dependency on bus_space_write_8()

Re: CVS commit: src/sys/kern (kern_event.c)

2021-01-21 Thread Paul Goyette
Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. On Thu, 21 Jan 2021, Paul Goyette wrote: This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491:

Re: CVS commit: src/sys/kern (kern_event.c)

2021-01-21 Thread Paul Goyette
This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1) != count(0), nmarker=1 [ 28.0253983] cpu0: Begin traceback... [ 28.0253983] vpanic() at

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

2021-01-21 Thread Jared McNeill
This driver is not 64-bit safe and should not be enabled on aarch64 as-is. I think before turning it on we should restrict it to the lower 1GB of memory like the Pi3 models where we know it at least has a chance of working. You can do this easily by creating a restrictive tag using

Re: CVS commit: src/sys/kern

2021-01-21 Thread Tom Spindler (moof)
I believe it's this change that's made my vbox image panic at the drop of a hat; while it occasionally panics before it even hits single user, it also consistently panics when starting syslogd (even from single-user): panic: kqueue_scan,1491: kq=0xc779aeff6dc0 kq->kq_count(1) != count(0),

Re: CVS commit: src/sys/dev

2021-01-21 Thread Jason Thorpe
> On Jan 21, 2021, at 12:00 AM, Martin Husemann > wrote: > > On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote: >> Module Name: src >> Committed By:reinoud >> Date:Wed Jan 20 19:46:48 UTC 2021 >> > [..] >> Log Message: >> Add VirtIO PCI v1.0 attachments

Re: CVS commit: src/sys/dev

2021-01-21 Thread Martin Husemann
On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote: > Module Name: src > Committed By: reinoud > Date: Wed Jan 20 19:46:48 UTC 2021 > [..] > Log Message: > Add VirtIO PCI v1.0 attachments and fix the drivers affected. > > * virtio on sparc64 attaches but is it not

re: CVS commit: src/sys/arch

2021-01-20 Thread matthew green
"Nia Alarie" writes: > Module Name: src > Committed By: nia > Date: Wed Jan 20 13:22:08 UTC 2021 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC MODULAR XEN3_DOM0 XEN3_DOMU > src/sys/arch/evbarm/conf: OPENBLOCKS_AX3 > src/sys/arch/i386/conf: GENERIC MODULAR

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

2021-01-20 Thread Martin Husemann
On Tue, Jan 19, 2021 at 07:19:51PM +0100, Martin Husemann wrote: > On Tue, Jan 19, 2021 at 12:35:10AM +, Jason R Thorpe wrote: > > Module Name:src > > Committed By: thorpej > > Date: Tue Jan 19 00:35:10 UTC 2021 > > > > Modified Files: > >

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

2021-01-19 Thread Martin Husemann
On Tue, Jan 19, 2021 at 12:35:10AM +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Tue Jan 19 00:35:10 UTC 2021 > > Modified Files: > src/sys/arch/arm/sunxi: sunxi_sramc.c > > Log Message: > Use device_compatible_entry / of_search_compatible()

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

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

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

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:

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

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

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

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

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

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.

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

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.

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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! --

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:

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

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

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

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):

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

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

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

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

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: >>

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

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,

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

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 >

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 >

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

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

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

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

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

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, |

  1   2   3   4   5   6   7   8   9   10   >