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
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Fri Apr 23 15:21:49 UTC 2021
>
> Modified Files:
> src/distrib/sets/lists/debug: mi
>
> Log Message:
> Add lto-dump.debug.
thanks! i had changed this, but failed to commit.
.mrg.
On 2021/04/18 0:38, Joerg Sonnenberger wrote:
On Sat, Apr 17, 2021 at 01:25:57PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat Apr 17 13:25:57 UTC 2021
Modified Files:
src/sys/arch/powerpc/include/booke: vmparam.h
Log Message:
Sync MAXfoo params
On 18.04.2021 16:12, Christos Zoulas wrote:
In article <20210418085205.10b75f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Sun Apr 18 08:52:04 UTC 2021
Modified Files:
src/usr.bin/xlint/lint1: err.c externs1.h lint1.h
In article <20210418085205.10b75f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Sun Apr 18 08:52:04 UTC 2021
>
>Modified Files:
> src/usr.bin/xlint/lint1: err.c externs1.h lint1.h
>
>Log Message:
>lint: add error_at,
On Sat, Apr 17, 2021 at 01:25:57PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sat Apr 17 13:25:57 UTC 2021
>
> Modified Files:
> src/sys/arch/powerpc/include/booke: vmparam.h
>
> Log Message:
> Sync MAXfoo params with oea:
>
> MAXTSIZ: 512MB ->
"Andreas Gustafsson" wrote:
> Module Name: src
> Committed By: gson
> Date: Sat Apr 10 10:32:57 UTC 2021
>
> Modified Files:
>
> src/external/bsd/atf/dist/tools: atf-run.1 atf-run.cpp
>
> Log Message:
>
> Add support for running individual test cases under isolation.
Thank you!
"Martin Husemann" writes:
> Module Name: src
> Committed By: martin
> Date: Thu Apr 8 15:06:50 UTC 2021
>
> Removed Files:
> src/crypto/external/bsd/openssl/lib/libcrypto/arch/sparc: modes.inc
>
> Log Message:
> Do not pretend we have GHASH asm code
please see my other message --
joerg> Just the libs should be enough and ideally,
jk> It appears that we would need to add the 'elftoolchain' subdirectory to
jk> "src/external/bsd/Makefile" for the global includes run to work.
This should be fixed now.
Regards,
Joseph Koshy
On Thu, Apr 08, 2021 at 05:53:42PM +0100, Joseph Koshy wrote:
> On Thu, Apr 08, 2021 at 01:51:30PM +0200, Joerg Sonnenberger wrote:
> jk> Redo r1.288: traverse the complete imported Elftoolchain tree during
> jk> a build.
>
> js> Just the libs should be enough and ideally, libelf and libdwarf
>
On Thu, Apr 08, 2021 at 01:51:30PM +0200, Joerg Sonnenberger wrote:
jk> Redo r1.288: traverse the complete imported Elftoolchain tree during
jk> a build.
js> Just the libs should be enough and ideally, libelf and libdwarf
js> are folded into the main .WAIT groups. There is a global includes
js>
On Thu, Apr 08, 2021 at 08:10:30AM +, Joseph Koshy wrote:
> Module Name: src
> Committed By: jkoshy
> Date: Thu Apr 8 08:10:30 UTC 2021
>
> Modified Files:
> src/lib: Makefile
>
> Log Message:
> Redo r1.288: traverse the complete imported Elftoolchain tree during a build.
Hi,
Thanks for your quick fix!
I will rebuild userland and ruby30-base.
On Wed, Apr 7, 2021 at 7:00 PM Simon Burge wrote:
>
> Ryo ONODERA wrote:
>
> > Hi,
> >
> > dtrace support of pkgsrc/lang/ruby30-base uses drti.o.
> > Without drti.o, ruby30-base is not buildable with dtrace option
> > and
Ryo ONODERA wrote:
> Hi,
>
> dtrace support of pkgsrc/lang/ruby30-base uses drti.o.
> Without drti.o, ruby30-base is not buildable with dtrace option
> and dtrace option is enabled by default.
>
> Could you please put drti.o back?
Thanks for the bug report. I've reverted this change.
Hi,
dtrace support of pkgsrc/lang/ruby30-base uses drti.o.
Without drti.o, ruby30-base is not buildable with dtrace option
and dtrace option is enabled by default.
Could you please put drti.o back?
Thank you.
On Mon, Mar 29, 2021 at 10:57 AM Simon Burge wrote:
>
> Module Name:src
>
> I think this is a misunderstanding.
indeed. sorry for the noise and mis-request.
.mrg.
06.04.2021 20:55:54 matthew green :
>> Module Name: src
>> Committed By: rillig
>> Date: Mon Apr 5 11:27:04 UTC 2021
>>
>> Modified Files:
>> src/external/mpl/bind/dist/bin/check: check-tool.c named-checkconf.c
>> named-checkzone.c
> [ ... ]
>>
In article <9374.1617735...@splode.eterna.com.au>,
matthew green wrote:
>> Module Name: src
>> Committed By:rillig
>> Date:Mon Apr 5 11:27:04 UTC 2021
>>
>> Modified Files:
>> src/external/mpl/bind/dist/bin/check: check-tool.c named-checkconf.c
>>
> Module Name: src
> Committed By: rillig
> Date: Mon Apr 5 11:27:04 UTC 2021
>
> Modified Files:
> src/external/mpl/bind/dist/bin/check: check-tool.c named-checkconf.c
> named-checkzone.c
[ ... ]
> src/external/mpl/bind/dist/lib/ns/tests: nstest.h
>
> Log Message:
On Tue, Apr 06, 2021 at 00:47:00 +, Roland Illig wrote:
> The previous "table" was an insult to any reader. It was unsorted,
> listed the functions shuffled, and was not even formatted consistently.
That's pretty rude. Please, tone down your commit "messages".
-uwe
"Christos Zoulas" wrote:
> Module Name: src
> Committed By: christos
> Date: Mon Apr 5 22:52:03 UTC 2021
>
> Modified Files:
>
> src/sys/conf: Makefile.kern.inc
>
> Log Message:
>
> Don't use /usr/bin/time (it is not portable)
Oops, that bit wasn't meant to sneak in. Thanks for
Robert Elz wrote:
> Date:Fri, 2 Apr 2021 06:31:53 +
> From:"Simon Burge"
> Message-ID: <20210402063153.773c7f...@cvs.netbsd.org>
>
> | Add an XXX reminder to convert at(1) to use parsedate(3) in .
>
> If that's intended as an optional facility (at -d ... or
Date:Fri, 2 Apr 2021 06:31:53 +
From:"Simon Burge"
Message-ID: <20210402063153.773c7f...@cvs.netbsd.org>
| Add an XXX reminder to convert at(1) to use parsedate(3) in .
If that's intended as an optional facility (at -d ... or something),
then fine, but please
"Rin Okuyama" wrote:
> Module Name: src
> Committed By: rin
> Date: Fri Apr 2 12:11:42 UTC 2021
>
> Log Message:
>
> For ports with __HAVE_LEGACY_INTRCNT, turn intrcnt[] and derived
> variables into u_int, to match with kern/subr_evcnt.c.
Thanks Rin!
Cheers,
Simon.
Ugh. Can we please stop making these hacky one-offs in "shared by all PowerPC
platforms" code? This actually points to a deeper problem in the pmap code
that needs to be addressed correctly.
> On Apr 1, 2021, at 3:02 PM, Michael Lorenz wrote:
>
> Module Name: src
> Committed By: macallan
>
On Fri, Apr 02, 2021 at 12:45:28AM +0200, Roland Illig wrote:
> For simple cases I agree with Matthew that parentheses should not be
> required. Looking through the src tree, I noticed though that the vast
> majority of the code uses the redundant parentheses, so I also agree
> with Christos that
On 31.03.2021 11:03, Robert Elz wrote:
Here, as I recall it, the issue only arose because of something either
lint or indent was doing, or wanted to do. I don't recall which, but
I do not remember any earlier complaints from anyone that they couldn't
understand code because of missing ()
Date:Wed, 31 Mar 2021 03:03:53 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| There are 3 x 'sizeof(' in the tree compared to 'sizeof ' in '*.c' and
| I am counting 'sizeof (' as 'sizeof ':
|
| 191337 'sizeof('
| 63508 'sizeof '
|
On Wed, Mar 31, 2021 at 12:38:20PM +1100, matthew green wrote:
> i already did in the other thread -- apply the existing
> () rule. aka, avoid it unless it helps comprehension,
> which means simple sizeof can avoid it, but anything
> slightly complex should not. this means that all the
> fun
In article <6734.1617154...@splode.eterna.com.au>,
matthew green wrote:
>Christos Zoulas writes:
>> In article <20900.1616977...@splode.eterna.com.au>,
>> matthew green wrote:
>> >> Log Message:
>> >> Clarify and explain the rationale for parentheses in sizeof and return as
>> >> discussed.
>>
Christos Zoulas writes:
> In article <20900.1616977...@splode.eterna.com.au>,
> matthew green wrote:
> >> Log Message:
> >> Clarify and explain the rationale for parentheses in sizeof and return as
> >> discussed.
> >
> >+* a function call. We always parenthesize the sizeof expression
In article ,
John Klos wrote:
>Log Message:
>Use the same options like m4 (-g turns on GNU, -G turns off GNU) Suggested
>by uwe@
>
>It seems, based on comparing netbsd-9 and -current, that the default was
>-g (GNU on), and is now -G (GNU off). Should the default be mentioned in
>the man page?
Log Message:
Use the same options like m4 (-g turns on GNU, -G turns off GNU) Suggested
by uwe@
It seems, based on comparing netbsd-9 and -current, that the default was
-g (GNU on), and is now -G (GNU off). Should the default be mentioned in
the man page?
John
In article <20900.1616977...@splode.eterna.com.au>,
matthew green wrote:
>> Log Message:
>> Clarify and explain the rationale for parentheses in sizeof and return as
>> discussed.
>
>+* a function call. We always parenthesize the sizeof expression for
>+* consistency.
>
>i
> Log Message:
> Clarify and explain the rationale for parentheses in sizeof and return as
> discussed.
+* a function call. We always parenthesize the sizeof expression for
+* consistency.
i object. this discussion was not finished.
.mrg.
On 27/03/2021 21:59, Christos Zoulas wrote:
In article <12312.1616877...@splode.eterna.com.au>,
matthew green wrote:
Sounds good. Will it mean that the following code is also preferred to
use parentheses? I like the simplicity without the parentheses, but for
consistency and simplicity of
In article <12312.1616877...@splode.eterna.com.au>,
matthew green wrote:
>> Sounds good. Will it mean that the following code is also preferred to
>> use parentheses? I like the simplicity without the parentheses, but for
>> consistency and simplicity of the rule set, I'd also accept the
>>
> Sounds good. Will it mean that the following code is also preferred to
> use parentheses? I like the simplicity without the parentheses, but for
> consistency and simplicity of the rule set, I'd also accept the
> parenthesized version.
>
> snprintf(buf, sizeof buf, "%s%s", arg1, arg2);
> On Mar 27, 2021, at 8:51 AM, Roland Illig wrote:
>
> On 27.03.2021 08:59, Christos Zoulas wrote:
>> I think we should document we prefer the parenthesized version in style
>> and call it a day.
>
> Sounds good. Will it mean that the following code is also preferred to
> use parentheses? I
On 27.03.2021 08:59, Christos Zoulas wrote:
I think we should document we prefer the parenthesized version in style
and call it a day.
Sounds good. Will it mean that the following code is also preferred to
use parentheses? I like the simplicity without the parentheses, but for
consistency
In article ,
Valery Ushakov wrote:
>On Sat, Mar 27, 2021 at 01:44:07 +0100, Roland Illig wrote:
>
>> On 27.03.2021 00:16, Valery Ushakov wrote:
>> > On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
>> > > To me, writing 'sizeof expr' is clearer than 'sizeof(expr)' since
>> > >
On Sat, Mar 27, 2021 at 01:44:07 +0100, Roland Illig wrote:
> On 27.03.2021 00:16, Valery Ushakov wrote:
> > On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
> > > To me, writing 'sizeof expr' is clearer than 'sizeof(expr)' since
> > > 'sizeof' is not a function, same as with 'return'.
On 27.03.2021 00:16, Valery Ushakov wrote:
On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
To me, writing 'sizeof expr' is clearer than 'sizeof(expr)' since
'sizeof' is not a function, same as with 'return'.
Did I misinterpret the style guide in this regard?
We do want it to look
>
> There are several forms of writing sizeof:
>
> 1. sizeof expr
> 2. sizeof(expr)
> 3. sizeof (expr)
> 4. sizeof(type)
> 5. sizeof (type)
>
> I thought that the point of the rule you cited was to discourage forms 3
> and 5. Does the rule also discourage form 1, and if so, why?
>
> To me,
On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
> > > Log Message:
> > > lint: in malloc calls, use 'sizeof *ptr' instead of 'sizeof(type)'
> >
> > style says "sizeof(" not "sizeof "
> >
> > * Casts and sizeof's are not followed by a space.
>
> There are several forms of
On 26.03.2021 23:18, Christos Zoulas wrote:
In article <20210326203108.3a4e5f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Fri Mar 26 20:31:07 UTC 2021
Modified Files:
src/usr.bin/xlint/common: tyname.c
In article <20210326203108.3a4e5f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 26 20:31:07 UTC 2021
>
>Modified Files:
> src/usr.bin/xlint/common: tyname.c
> src/usr.bin/xlint/lint1: cgram.y decl.c err.c
Yes, the binary is mips64-n32. There is no n32 for mips32.
I moved the CPUFLAGS=-n32 assignment to the 64 bit
portion of the Makefile.
christos
> On Mar 16, 2021, at 12:14 AM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:
On Sun, Mar 07, 2021 at 01:09:43PM +, Nathanial Sloss wrote:
> This is to compenstate for the behaviour in NetBSD current that pad(4) will
> no longer output 0's when its corresponding audio(4) device is not active.
>
> I believe that this new pad(4) behaviour is not present in -9 and -8.
I
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Mon Mar 15 18:13:54 UTC 2021
>
> Modified Files:
> src/sys/arch/evbmips/stand/sbmips: Makefile.bootprogs
>
> Log Message:
> - 32 bit mips uses oabi, don't force it to n32.
> - compile assembly code with
At Fri, 12 Mar 2021 08:03:24 +,
Nia Alarie wrote:
> Committed By: nia
> Date: Fri Mar 12 08:03:24 UTC 2021
>
> Modified Files:
> src/share/man/man4: hdaudio.4
>
> Log Message:
> Clarify problem.
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.18 -r1.19
On Fri, Mar 12, 2021 at 05:02:00PM +1100, matthew green wrote:
> > Modified Files:
> > src/share/man/man4: hdaudio.4
> >
> > Log Message:
> > Mention that formats with >16-bit precision cannot yet be used
>
> i'm not near a system to test right now, but when i added
> support for floating
> Modified Files:
> src/share/man/man4: hdaudio.4
>
> Log Message:
> Mention that formats with >16-bit precision cannot yet be used
i'm not near a system to test right now, but when i added
support for floating point WAVE files to audioplay, i've
converted from float32 or float64 to signed
In article ,
Valery Ushakov wrote:
>On Thu, Mar 11, 2021 at 10:15:05 -0500, Christos Zoulas wrote:
>
>> Module Name: src
>> Committed By:christos
>> Date:Thu Mar 11 15:15:05 UTC 2021
>>
>> Modified Files:
>> src/usr.bin/sed: main.c sed.1
>>
>> Log Message:
>> Add
On Thu, Mar 11, 2021 at 10:15:05 -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Mar 11 15:15:05 UTC 2021
>
> Modified Files:
> src/usr.bin/sed: main.c sed.1
>
> Log Message:
> Add -G to support GNU extensions
This is inverse of m4(1) where
matthew green writes:
> could this be done with include and "no foo" statement?
> eg, like sys/arch/sparc/conf/INSTALL does.
Maybe, but I'm not sure it will end up working. Right now we don't know
if any of the missing things will be trouble, and even if we do move to
include/no I'd like to
"Greg Troxel" writes:
> Module Name: src
> Committed By: gdt
> Date: Fri Mar 5 20:30:56 UTC 2021
>
> Modified Files:
> src/sys/arch/amd64/conf: XEN3_DOM0
>
> Log Message:
> XEN3_DOM0: Approach GENERIC
>
> When processed to remove comments, blank lines, normalize whitespace,
> and
On Sun 28 Feb 2021 at 09:04:28 +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Sun Feb 28 09:04:28 UTC 2021
>
> Modified Files:
> src/usr.bin/resize: Makefile
>
> Log Message:
> disable the rule to copy resize.c since it fails on r/o src trees:
>
> cp:
"Nia Alarie" writes:
> Module Name: src
> Committed By: nia
> Date: Fri Feb 26 10:56:48 UTC 2021
>
> Modified Files:
> src/share/man/man4/man4.i386: intro.4
>
> Log Message:
> Remove extremely outdated list of supported devices
be nice to have a link to isa(4), eisa(4), and pci(4),
Too bad, looks like they just made a copy of the FreeBSD changes. I will revert.
christos
> On Feb 25, 2021, at 6:47 PM, Rin Okuyama wrote:
>
> Hi,
>
> This does not work since nvi requires non-standard wregex API, whose
> ``char *'' arguments are replaced by ``wchar_t *'' ones:
>
>
Hi,
This does not work since nvi requires non-standard wregex API, whose
``char *'' arguments are replaced by ``wchar_t *'' ones:
https://mail-index.netbsd.org/tech-userlevel/2008/08/06/msg000960.html
https://mail-index.netbsd.org/tech-userlevel/2008/08/06/msg000967.html
In principle, we can
In article <5c9e716-7ec1-9c7d-a7cb-21f08946...@invisible.ca>,
Jared McNeill wrote:
>Building tools on macOS:
>
>/Users/jmcneill/netbsd/git-src/tools/compat/../../lib/libc/regex/regcomp.c:1585:8:
>
>error: implicit declaration of function 'reallocarray' is invalid
> in C99
Building tools on macOS:
/Users/jmcneill/netbsd/git-src/tools/compat/../../lib/libc/regex/regcomp.c:1585:8:
error: implicit declaration of function 'reallocarray' is invalid
in C99 [-Werror,-Wimplicit-function-declaration]
ncs = reallocarray(p->g->sets, p->g->ncsets + 1,
On Mon, 22 Feb 2021, Ryo Shimizu wrote:
I think this condition is not necessary since cpu_idle() is just called from
idle_loop(),
and ci_intr_depth is always zero at this time.
Ah yes, my mistake! Please feel free to revert this commit as part of
your proposed change.
> On Feb 22, 2021, at 11:49 AM, Ryo Shimizu wrote:
>
> Ah, You are quite right!
> idle/# lwp is provided and assigned for each CPU, so curcpu() obtained from
> idle lwp was always the same.
> So, there's no need to move curcpu() to after DISABLE_INTERRUPT.
Please make sure to add a comment
>> In addition, because of the possibility of kpreemption (but aarch64 has =
>no KPREEMPT yet),
>> the acquisition of curcpu() is moved to after DISABLE_INTERRUPT and got =
>the following.
>>
>[snip]
>
>
>>
>> Is this ok?
>>
>
>Looks good - I wonder if the fact that curcpu is an invariant for
On 22/02/2021 10:40, Ryo Shimizu wrote:
Module Name:src
Committed By: jmcneill
Date: Sun Feb 21 23:37:10 UTC 2021
Modified Files:
src/sys/arch/aarch64/aarch64: idle_machdep.S
Log Message:
When waking from cpu_idle(), only call dosoftints if ci_intr_depth == 0
To
>Module Name: src
>Committed By: jmcneill
>Date: Sun Feb 21 23:37:10 UTC 2021
>
>Modified Files:
> src/sys/arch/aarch64/aarch64: idle_machdep.S
>
>Log Message:
>When waking from cpu_idle(), only call dosoftints if ci_intr_depth == 0
>
>
>To generate a diff of this commit:
>cvs
801 - 900 of 11269 matches
Mail list logo
