On Tue, Aug 17, 2021 at 11:39:26PM +, Taylor R Campbell wrote:
> >
> > Log Message:
> > skip symbol tables that were unloaded again to avoid EFAULT when reading
> > ksyms.
> >
> > also restore TAILQ_FOREACH idiom.
>
> This change isn't quite right: Reading past st = ksyms_last_snapshot
> in
> Module Name:src
> Committed By: mlelstv
> Date: Sun Jul 18 06:57:28 UTC 2021
>
> Modified Files:
> src/sys/kern: kern_ksyms.c
>
> Log Message:
> skip symbol tables that were unloaded again to avoid EFAULT when reading
> ksyms.
>
> also restore TAILQ_FOREACH idiom.
On 2021/08/09 7:26, Rin Okuyama wrote:
- Initialize LIST_HEAD.
Hmm, since HEADs are static, this is not necessary. But, it should be
a good practice to initialize HEADs always, IMO...
Thanks,
rin
Sorry, no idea what happened with that. And thanks Martin for fixing it.
kre
The script no longer works:
Starting devpubd.
/libexec/devpubd-hooks/02-wedgenames: 164: Syntax error: end of file unexpected
(expecting "done")
Take care,
Jared
On Thu, 5 Aug 2021, Robert Elz wrote:
Module Name:src
Committed By: kre
Date: Thu Aug 5 12:52:47 UTC 2021
Hi,
On 2021/08/06 17:58, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Fri Aug 6 08:58:42 UTC 2021
Modified Files:
src/sys/arch/arm/xscale: i80321_intr.h
Log Message:
Do *NOT* lower IPL in i80321_splraise().
Fix various strange crashes for DIAGNOSTIC
Date:Mon, 2 Aug 2021 20:02:28 +0900
From:Rin Okuyama
Message-ID: <21dae7de-f153-2e53-4e66-cc61c8241...@gmail.com>
quoting Michael van Elst:
| > If you insist on a separate barrier, one name would be USERDEVICEPATHS
| > or short UDEV.
UDEV (or UDEVS) sounds good
On 2021/08/02 19:15, Michael van Elst wrote:
On Mon, Aug 02, 2021 at 11:27:22AM +0200, Michael van Elst wrote:
On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
Hi,
this commit causes:
rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
for systems with
On Mon, Aug 02, 2021 at 11:27:22AM +0200, Michael van Elst wrote:
> On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
> > Hi,
> >
> > this commit causes:
> >
> > rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
> >
> > for systems with MKZFS=no.
> >
> >
On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
> Hi,
>
> this commit causes:
>
> rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
>
> for systems with MKZFS=no.
>
> Install /etc/rc.d/zfs for everyone? This should be harmless; the script
> properly checks
On Mon, Aug 02, 2021 at 12:44:01PM +0700, Robert Elz wrote:
> Date:Mon, 2 Aug 2021 11:54:27 +0900
> From:Rin Okuyama
> Message-ID:
>
> | Install /etc/rc.d/zfs for everyone?
>
> Add a new dummy rc.d script (like LOGIN or DISKS)
> have devpubd come before that, and
Date:Mon, 2 Aug 2021 11:54:27 +0900
From:Rin Okuyama
Message-ID:
| Install /etc/rc.d/zfs for everyone?
Add a new dummy rc.d script (like LOGIN or DISKS)
have devpubd come before that, and everything
which should come later require it.
That's cleaner. We should
The H6 BSP provides some clues:
#if defined(CONFIG_ARCH_SUN8IW12) \
|| defined(CONFIG_ARCH_SUN8IW15) \
|| defined(CONFIG_ARCH_SUN50IW3) \
|| defined(CONFIG_ARCH_SUN50IW6)
#define SUNXI_UART_FIFO_SIZE256
#elif defined(CONFIG_ARCH_SUN3IW1)
#define
Hi,
this commit causes:
rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
for systems with MKZFS=no.
Install /etc/rc.d/zfs for everyone? This should be harmless; the script
properly checks existence of /sbin/zfs, i.e., MKZFS=yes.
Alternatively, autogen
> On Jul 31, 2021, at 3:17 AM, Tobias Nygren wrote:
>
> It's not possible to deduce from the manual what DesignWare revision
> is used but I guess I can go over the data sheets of currently
> released SoCs and build a matrix of the proper values regardless
> of DesignWare revision.
Have the
On Fri, 30 Jul 2021 22:36:45 +0200
Tobias Nygren wrote:
> On Fri, 30 Jul 2021 17:25:46 -0300 (ADT)
> Jared McNeill wrote:
>
> > Why only A20?
>
> It is the hardware I have on hand. If you know specifically which
> SoCs need this, the compat_data array can be extended.
> I guess maybe these
On Fri, 30 Jul 2021 17:25:46 -0300 (ADT)
Jared McNeill wrote:
> Why only A20?
It is the hardware I have on hand. If you know specifically which
SoCs need this, the compat_data array can be extended.
I guess maybe these also?
allwinner,sun4i-a10
allwinner,sun6i-a31
Why only A20?
On Fri, 30 Jul 2021, Tobias Nygren wrote:
Module Name:src
Committed By: tnn
Date: Fri Jul 30 12:46:46 UTC 2021
Modified Files:
src/sys/arch/arm/sunxi: sunxi_platform.c
src/sys/dev/ic: com.c
Log Message:
com(4): fix FIFO for DW_APB on Allwinner
On Tue, Jul 27, 2021 at 12:22:18AM +0300, Valery Ushakov wrote:
> I'm not sure what is the discussion you are referring to, but it's not
> a matter of a simple rewording. "It's complicated", as it ties into a
> few other things, so ideally it needs a coordinated change to several
> man pages.
On Mon, Jul 26, 2021 at 21:04:37 +, nia wrote:
> On Mon, Jul 26, 2021 at 09:01:51PM +, nia wrote:
> > On Mon, Jul 26, 2021 at 11:55:24PM +0300, Valery Ushakov wrote:
> > > On Mon, Jul 26, 2021 at 20:17:10 +, Nia Alarie wrote:
> > >
> > > > Module Name:src
> > > > Committed By:
On Mon, 26 Jul 2021, nia wrote:
"Some modern terminals may display characters with the standout
attribute set identically to those with the bold or reverse attribute
set."
I would remove the word "modern" completely.
++--+--+
|
On Mon, Jul 26, 2021 at 09:01:51PM +, nia wrote:
> On Mon, Jul 26, 2021 at 11:55:24PM +0300, Valery Ushakov wrote:
> > On Mon, Jul 26, 2021 at 20:17:10 +, Nia Alarie wrote:
> >
> > > Module Name: src
> > > Committed By: nia
> > > Date: Mon Jul 26 20:17:10 UTC 2021
> >
On Mon, Jul 26, 2021 at 11:55:24PM +0300, Valery Ushakov wrote:
> On Mon, Jul 26, 2021 at 20:17:10 +, Nia Alarie wrote:
>
> > Module Name:src
> > Committed By: nia
> > Date: Mon Jul 26 20:17:10 UTC 2021
> >
> > Modified Files:
> > src/lib/libcurses:
On Mon, Jul 26, 2021 at 20:17:10 +, Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Mon Jul 26 20:17:10 UTC 2021
>
> Modified Files:
> src/lib/libcurses: curses_standout.3
>
> Log Message:
> The BUGS sections is incorrect again for "modern" terminals.
>
>
Hi,
Thank you for suggestions, I will take them in mind for future
commits. I believe I will avoid doing such big commits in the future
though, just I had submitted them all in my own PR some time ago... I
actually asked about the strategy in IRC and I got comment to do one
commit this time, just
On 2021/07/25 6:32, Joerg Sonnenberger wrote:
On Sat, Jul 24, 2021 at 05:27:26AM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat Jul 24 05:27:26 UTC 2021
Modified Files:
src/lib/libc/arch/powerpc/string: Makefile.inc
Log Message:
For evbppc, use C
On 2021/07/25 6:31, Andrius Varanavicius wrote:
Module Name:src
Committed By: andvar
Date: Sat Jul 24 21:31:39 UTC 2021
...
Log Message:
Fix all remaining typos, mainly in comments but also in few definitions and log
messages, reported by me in PR kern/54889.
Also fixed some
I guess I should revert this particular change then. Yes, I saw PGOFSET
definition and assumed it's a typo too, just too widely used and like you
said historical value. In some header files PGOFSET had a comment: "byte
offset into page" next to it.
On Sun, Jul 25, 2021, 00:53 Izumi Tsutsui
> Log Message:
> Fix all remaining typos, mainly in comments but also in few definitions and
> log messages, reported by me in PR kern/54889.
> Also fixed some additional typos in comments, found on review of same files
> or typos.
:
> cvs rdiff -u -r1.51 -r1.52
On Sat, Jul 24, 2021 at 05:27:26AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sat Jul 24 05:27:26 UTC 2021
>
> Modified Files:
> src/lib/libc/arch/powerpc/string: Makefile.inc
>
> Log Message:
> For evbppc, use C version of bcopy(3), memcpy(3),
On Mon, Jul 19, 2021 at 01:33:53AM +, David A. Holland wrote:
> Part 3; cvs randomly didn't commit all the files the first time, still
> hunting down the files it skipped.
ok, I'm pretty sure that's the lot.
--
David A. Holland
dholl...@netbsd.org
On Fri, 16 Jul 2021 12:44:18 +0200
Frank Kardel wrote:
> I am not sure why NO_FOLLOW was there and if we want to keep it how
>
> we would handle named wedges. We could create a /dev/wedgedev from
>
> devpubd with hard links to the devices - that would work with ZFS but
>
> is really ugly.
>
Hi !
This triggered an unexpected side effect.
I have my ZFS vdev on gpt partitions as wedges.
I configured the vdevs via the /dev/wedges/* symlinks via the wedge names.
data 1.28T 424G 888G - 4% 32% 1.31x
ONLINE -
raidz2 1.28T 424G
On 15/07/2021 04:25, Tohru Nishimura wrote:
Module Name:src
Committed By: nisimura
Date: Thu Jul 15 03:25:50 UTC 2021
Modified Files:
src/sys/dev/usb: if_mue.c uchcom.c
Log Message:
explanation typo
To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61
> On Jul 15, 2021, at 12:06 AM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Jul 14 13:24:59 UTC 2021
>>
>> Modified Files:
>> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h
>>
>> Log Message:
>>
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Wed Jul 14 13:24:59 UTC 2021
>
> Modified Files:
> src/external/gpl3/gcc/dist/gcc/ginclude: stddef.h
>
> Log Message:
> clang does not support __float128 in our configuration and i386
shouldn't you
On 04/07/2021 23:11, Joerg Sonnenberger wrote:
On Sun, Jul 04, 2021 at 06:55:47AM +, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Sun Jul 4 06:55:47 UTC 2021
Modified Files:
src/common/lib/libc/arch/aarch64/atomic: atomic_nand_16.S
On Sun, Jul 04, 2021 at 06:55:47AM +, Nick Hudson wrote:
> Module Name: src
> Committed By: skrll
> Date: Sun Jul 4 06:55:47 UTC 2021
>
> Modified Files:
> src/common/lib/libc/arch/aarch64/atomic: atomic_nand_16.S
> atomic_nand_32.S atomic_nand_64.S atomic_nand_8.S
>
On Thu, Jul 01, 2021 at 12:25:51AM -0400, Christos Zoulas wrote:
> Modified Files:
> src/sys/kern: vfs_vnops.c
>
> Log Message:
> don't clear the error before we use it to determine if we are moving or
> duping.
oh ffs...
*goes to soak head*
--
David A. Holland
dholl...@netbsd.org
On Wed, Jun 30, 2021 at 06:42:21PM +0900, Rin Okuyama wrote:
> /home/source/ab/HEAD/src/sys/kern/vfs_vnops.c:357:11: error: 'vp' may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
> 357 | *ret_vp = vp;
> | ^~~~
> cc1: all warnings being treated as
On 30/06/2021 15:13, Joerg Sonnenberger wrote:
On Tue, Jun 29, 2021 at 11:26:00PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Jun 29 23:26:00 UTC 2021
Modified Files:
src/sys/external/bsd/compiler_rt/dist/lib/builtins/arm: aeabi_cfcmp.S
On Tue, Jun 29, 2021 at 11:26:00PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Tue Jun 29 23:26:00 UTC 2021
>
> Modified Files:
> src/sys/external/bsd/compiler_rt/dist/lib/builtins/arm: aeabi_cfcmp.S
> divmodsi4.S divsi3.S modsi3.S
>
> Log
On Tue, Jun 29, 2021 at 10:40:54PM +, David A. Holland wrote:
> Module Name: src
> Committed By: dholland
> Date: Tue Jun 29 22:40:54 UTC 2021
>
> Modified Files:
> src/external/cddl/osnet/sys/sys: vnode.h
> src/share/man/man9: errno.9 vnsubr.9
> src/sys/dev:
Hi,
GCC warns maybe-uninitialized for this commit (for some architectures and
optimization levels: https://releng.netbsd.org/builds/HEAD/202106292250Z/):
/home/source/ab/HEAD/src/sys/kern/vfs_vnops.c: In function 'vn_open':
/home/source/ab/HEAD/src/sys/kern/vfs_vnops.c:357:11: error: 'vp'
On Tue, 29 Jun 2021, Paul Goyette wrote:
Please note that both riastradh@ and dh@ have plans to ride this
version bump. You might want to delay any ``cvs up'' commands for
a short while.
:)
Looks like both commits are done, so ``cvs up'' should get you a
workable source tree.
On Tue, 29 Jun 2021, David A. Holland wrote:
Module Name:src
Committed By: dholland
Date: Tue Jun 29 22:39:21 UTC 2021
Modified Files:
src/sys/fs/puffs: puffs_vnops.c
src/sys/fs/union: union_vnops.c
src/sys/fs/unionfs: unionfs_subr.c
Oops, this is broken. I will fix shortly...
rin
On 2021/06/30 8:29, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Jun 29 23:29:12 UTC 2021
Modified Files:
src/lib/libc/arch/arm/gen: swapcontext.S
src/lib/libc/arch/arm/sys: __clone.S
Log
Please note that both riastradh@ and dh@ have plans to ride this
version bump. You might want to delay any ``cvs up'' commands for
a short while.
:)
On Tue, 29 Jun 2021, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Tue Jun 29 21:03:37 UTC 2021
Modified
On Wed, Jun 23, 2021 at 07:29:30AM +, Martin Husemann wrote:
> This (or the series) broke the non-wide char builds.
> Easy/quick reproducer: build.sh -m sun2 release
/home/builds/ab/HEAD/sun3/202106222020Z-tools/lib/gcc/m68k--netbsdelf/10.3.0/../../../../m68k--netbsdelf/bin/ld:
libhack.o: in
On Tue, Jun 22, 2021 at 07:49:09AM +, Brett Lymn wrote:
> Module Name: src
> Committed By: blymn
> Date: Tue Jun 22 07:49:09 UTC 2021
>
> Modified Files:
> src/lib/libcurses: addbytes.c
>
> Log Message:
> Rework the fix for lib/56224.
> Move the scroll check to
On 2021/06/16 19:23, Rin Okuyama wrote:
On 2021/06/16 18:15, Taylor R Campbell wrote:
Date: Wed, 16 Jun 2021 17:38:26 +0900
From: Rin Okuyama
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed:
On 2021/06/16 18:15, Taylor R Campbell wrote:
Date: Wed, 16 Jun 2021 17:38:26 +0900
From: Rin Okuyama
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/pad/pad.c", line 214
> Date: Wed, 16 Jun 2021 17:38:26 +0900
> From: Rin Okuyama
>
> KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
> [...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
> "/usr/src/sys/dev/pad/pad.c", line 214
Can you share `ident netbsd | grep
Hi,
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
# cd /usr/tests/usr.bin/mixerctl && atf-run
...
tc-start: ..., nflag
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/pad/pad.c", line 214
[...] cpu0: Begin
Date:Mon, 14 Jun 2021 03:56:48 +0200
From:Joerg Sonnenberger
Message-ID:
| This is even more true for multi-threaded applications
| (where POSIX explicitly suggests that requirement).
Sure, anything with fork() and threads has issues, that's messy.
Even I know
On Mon, Jun 14, 2021 at 01:33:51AM +0700, Robert Elz wrote:
> Date:Sat, 12 Jun 2021 23:13:54 +0200
> From:Joerg Sonnenberger
> Message-ID:
>
> Sorry, missed this message when I was cherry picking messages to read in
> a timely fashion.
>
> | On Wed, Jun 09, 2021
Date:Sat, 12 Jun 2021 23:13:54 +0200
From:Joerg Sonnenberger
Message-ID:
Sorry, missed this message when I was cherry picking messages to read in
a timely fashion.
| On Wed, Jun 09, 2021 at 01:03:20AM +0700, Robert Elz wrote:
| > after a vfork() the child can
On Wed, Jun 09, 2021 at 01:03:20AM +0700, Robert Elz wrote:
> It should, when it is workable for the application, make things
> faster, while also avoiding the vfork() perils. But only when
> it works -- after a vfork() the child can do anything (it should
> avoid touching its parent's state,
On Wed, 9 Jun 2021, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Wed Jun 9 23:22:51 UTC 2021
Modified Files:
src/sys/dev: dev_verbose.h
Log Message:
Use the localcount(9)-based module_hook mechanism to prevent the verbose
modules' code and data
Date:Tue, 8 Jun 2021 16:15:12 +
From:"Nia Alarie"
Message-ID: <20210608161512.1d7c3f...@cvs.netbsd.org>
| vfork.2: recommend posix_spawn instead
You might want to reconsider the wording there, posix_spawn() is
an alternative to [v]fork() + exec*(). Not just
On 2021/06/08 16:09, nia wrote:
On Tue, Jun 01, 2021 at 09:12:24PM +, Taylor R Campbell wrote:
audio(4): Set AUMODE_PLAY/RECORD only if asked _and_ supported.
If one is requested and _not_ supported, fail; otherwise we might
enter audio_write with a null play track and crash on KASSERT.
On Tue, Jun 01, 2021 at 09:12:24PM +, Taylor R Campbell wrote:
> audio(4): Set AUMODE_PLAY/RECORD only if asked _and_ supported.
>
> If one is requested and _not_ supported, fail; otherwise we might
> enter audio_write with a null play track and crash on KASSERT.
It looks like this is an
Christos Zoulas writes:
> In article , Joerg Sonnenberger
> wrote:
> >On Fri, Jun 04, 2021 at 10:20:24PM -, Christos Zoulas wrote:
> >> In article , Joerg Sonnenberger
> > wrote:
> >> >On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
> >> >> Module Name:src
> >> >>
In article , Joerg Sonnenberger wrote:
>On Fri, Jun 04, 2021 at 10:20:24PM -, Christos Zoulas wrote:
>> In article , Joerg Sonnenberger
> wrote:
>> >On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
>> >> Module Name: src
>> >> Committed By: christos
>> >> Date:
On Fri, Jun 04, 2021 at 10:20:24PM -, Christos Zoulas wrote:
> In article , Joerg Sonnenberger
> wrote:
> >On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
> >> Module Name: src
> >> Committed By: christos
> >> Date: Thu Jun 3 20:17:37 UTC 2021
> >>
In article , Joerg Sonnenberger wrote:
>On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Jun 3 20:17:37 UTC 2021
>>
>> Modified Files:
>> src/tests/lib/csu: h_ifunc_static.c
>>
>> Log
On Thu, Jun 03, 2021 at 04:17:37PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Jun 3 20:17:37 UTC 2021
>
> Modified Files:
> src/tests/lib/csu: h_ifunc_static.c
>
> Log Message:
> PR/56230: Jan-Benedict Glaw: arm oabi does not and will
Hmm, misleading commit log (code itself is correct). More precisely:
s/the last element of ksyms_symtabs/ksyms_last_snapshot/
Anyway, does this help you to reintroduce
"ksyms(4): Don't skip symbol tables that are soon to be freed."?
That KASSERT does not fire anymore for aarch64, as far as I
> Date: Wed, 2 Jun 2021 17:33:39 +0900
> From: Rin Okuyama
>
> On 2021/06/02 6:11, Taylor R Campbell wrote:
> > - KASSERT(filepos <= sizeof(struct ksyms_hdr) +
> > + KASSERT(filepos == sizeof(struct ksyms_hdr) +
> > ksyms_hdr.kh_shdr[SYMTAB].sh_size);
> ...
>
> This KASSERT fires at
Hi,
On 2021/06/02 6:11, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Tue Jun 1 21:11:52 UTC 2021
Modified Files:
src/sys/kern: kern_ksyms.c
Log Message:
ksyms(4): Don't skip symbol tables that are soon to be freed.
They will not actually be
Correction:
On 2021/06/01 7:10, Rin Okuyama wrote:
On 2021/05/31 23:35, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory
On 2021/05/31 23:35, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and
On 2021/05/31 23:32, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
The former is used by GCC, and the latter is by LLVM. Since libunwind was
derived from LLVM, it has never supported
On 2021/05/31 23:30, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 11:41:22AM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon May 31 11:41:22 UTC 2021
Modified Files:
src/sys/lib/libunwind: Registers.hpp unwind_registers.S
Log Message:
...
-
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
> Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and double register in the
space. That's what the
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
> There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
> The former is used by GCC, and the latter is by LLVM. Since libunwind was
> derived from LLVM, it has never supported the former. This results in
> crashes for
On Mon, May 31, 2021 at 11:41:22AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Mon May 31 11:41:22 UTC 2021
>
> Modified Files:
> src/sys/lib/libunwind: Registers.hpp unwind_registers.S
>
> Log Message:
> ...
>
> - Introduce enum for flags.
Please
"Rin Okuyama" wrote:
> Module Name: src
> Committed By: rin
> Date: Sun May 30 07:20:00 UTC 2021
>
> Modified Files:
>
> src/sys/arch/arm/include/arm32: param.h
>
> Log Message:
>
> Include opt_param.h for MSGBUFSIZE ifdef _KERNEL_OPT.
Thanks Rin! I thought I had checked all the
Ok, I did not realize that all mips had switched.
christos
> On May 27, 2021, at 4:48 PM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Thu May 27 20:29:24 UTC 2021
>>
>> Modified Files:
>> src/share/mk:
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Thu May 27 20:29:24 UTC 2021
>
> Modified Files:
> src/share/mk: bsd.own.mk
>
> Log Message:
> mips64 only works with gcc-10
the MACHINE_CPU==mips test should cover mipsn64, that i assume
you mean here...
> On May 24, 2021, at 9:02 PM, matthew green wrote:
>
> this also probably fails to work as wanted (while not
> actually failing) for people who use "cvs -D .CVS", etc.
>
> it's kinda gross.
It is gross, and I considered removing it.
christos
signature.asc
Description: Message signed with
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Mon May 24 22:40:44 UTC 2021
>
> Modified Files:
> src/distrib/acorn32/stand: Makefile
>
> Log Message:
> PR/56207: Jan-Benedict Glaw: Handle error from find when removing CVS
> directories on a git repo.
On Mon, May 17, 2021 at 01:12:12PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Mon May 17 17:12:12 UTC 2021
>
> Modified Files:
> src: build.sh
>
> Log Message:
> for mercurial, use the latest revision instead of limiting the output to 1
>
I understand. Thanks!
rin
On 2021/05/09 9:20, Christos Zoulas wrote:
In article ,
Rin Okuyama wrote:
How about binutils?
http://cvsweb.netbsd.org/bsdweb.cgi/src/tools/binutils/Makefile#rev1.32
I don't think it makes a difference.
It seems that we need to mknative again for this:
In article ,
Rin Okuyama wrote:
>How about binutils?
>
>http://cvsweb.netbsd.org/bsdweb.cgi/src/tools/binutils/Makefile#rev1.32
I don't think it makes a difference.
>It seems that we need to mknative again for this:
Eventually, but not right now.
christos
How about binutils?
http://cvsweb.netbsd.org/bsdweb.cgi/src/tools/binutils/Makefile#rev1.32
It seems that we need to mknative again for this:
% find /usr/src/external/gpl3/binutils/usr.bin/ld -name '*.h' | xargs grep
HAVE_INITFINI_ARRAY
In article <20210506061816.94bb1f...@cvs.netbsd.org>,
Shoichi YAMAGUCHI wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: yamaguchi
>Date: Thu May 6 06:18:16 UTC 2021
>
>Modified Files:
> src/sys/net: if_spppsubr.c
>
>Log Message:
>do not clear destination address if there
On 2021/04/22 10:09, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Thu Apr 22 01:09:48 UTC 2021
Modified Files:
src/external/gpl3/binutils/dist/bfd: elf32-ppc.c elf64-ppc.c
Log Message:
Fix regression where ld(1) is trapped into infinite loop when
linking
On 30.04.2021 15:42, Tobias Nygren wrote:
On Tue, 20 Apr 2021 23:19:53 +
Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Tue Apr 20 23:19:53 UTC 2021
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: syms.mk
Log Message:
clang: fix
Hmm, it seems that we were the only ones that had RES_NOCHECKNAME enabled.
Everyone else uses check-names by default. So I am inclined to leave it as is.
christos
> On Apr 30, 2021, at 5:33 PM, Christos Zoulas wrote:
>
> Signed PGP part
> I guess I will undo it, because as I mentioned in a
I guess I will undo it, because as I mentioned in a separate mail it causes
other problems.
christos
> On Apr 30, 2021, at 5:18 PM, Robert Elz wrote:
>
>Date:Fri, 30 Apr 2021 12:07:49 -0400
>From:"Christos Zoulas"
>Message-ID:
Date:Fri, 30 Apr 2021 12:07:49 -0400
From:"Christos Zoulas"
Message-ID: <20210430160749.3a4dbf...@cvs.netbsd.org>
| src/include: resolv.h
|
| Log Message:
| Default to check-names for safety.
Please don't do that, check-names applies at the wrong place,
On Tue, 20 Apr 2021 23:19:53 +
Roland Illig wrote:
> Module Name: src
> Committed By: rillig
> Date: Tue Apr 20 23:19:53 UTC 2021
>
> Modified Files:
> src/external/bsd/compiler_rt/lib/clang/lib/netbsd: syms.mk
>
> Log Message:
> clang: fix build for installing
> Module Name:src
> Committed By: thorpej
> Date: Sat Apr 24 23:37:01 UTC 2021
>
> Log Message:
> Merge thorpej-cfargs branch:
>
> Simplify and make extensible the config_search() / config_found() /
> config_attach() interfaces: rather than having different variants for
> which
> (I haven't investigated exactly what's going on leading to ~5 KB-byte
> stack frames, but this shuts gcc up, at least, and the hypotheses
> sound plausible to me!)
this matches what i saw when looking at it. i was going to
test the exact same idea (noinline).
.mrg.
The condition is reversed. I will fix.
christos
> On Apr 26, 2021, at 10:31 PM, Rin Okuyama wrote:
>
> Hi,
>
> On 2021/04/26 7:25, Christos Zoulas wrote:
>> --- src/external/gpl3/gcc/usr.bin/cc1plus/Makefile:1.15 Sun Apr 11
>> 20:05:56 2021
>> +++
Hi,
On 2021/04/26 7:25, Christos Zoulas wrote:
--- src/external/gpl3/gcc/usr.bin/cc1plus/Makefile:1.15 Sun Apr 11 20:05:56 2021
+++ src/external/gpl3/gcc/usr.bin/cc1plus/Makefile Sun Apr 25 18:25:55 2021
(snip)
-.if ${MACHINE_ARCH} == "mipseb" || ${MACHINE_ARCH} == "mipsel"
+.if
On Sat, 24 Apr 2021, Robert Elz wrote:
Date:Sat, 24 Apr 2021 00:15:37 +
From:"Michael Lorenz"
Message-ID: <20210424001537.c5c83f...@cvs.netbsd.org>
| add an ioctl() to get a list of fonts currently available via wsfont
It seems to me it would be useful for that
Oh, I see from your code change to wsfontload.c that you intended
for the fi_numentries field to get copied out, it just doesn't seem
to happen.
I also see that the addr==NULL case happens if malloc() (in wsfontload.c)
failed - going ahead with the ioctl() in that case seems like a mistake,
Date:Sat, 24 Apr 2021 00:15:37 +
From:"Michael Lorenz"
Message-ID: <20210424001537.c5c83f...@cvs.netbsd.org>
| add an ioctl() to get a list of fonts currently available via wsfont
It seems to me it would be useful for that ioctl to copyout()
the fi_numentries
701 - 800 of 11236 matches
Mail list logo
