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
>> +++ src/external/gpl3/gcc/usr.bin/cc1plus/Ma
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 ${MACHINE
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,
optimi
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 f
"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, warning
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 -> 128M
"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! Th
"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 -- t
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
> js
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> ru
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.
Jus
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 dt
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.
Background
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
> Committ
> 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
> [ ... ]
>> src/external/mpl/bind/dist/lib/ns/tests
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
>> named-chec
> 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 n
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 some
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 d
"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 () around
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 case
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 for
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 object.
> 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 th
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
>> par
> 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);
FW
> 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 and
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
>> > > 'sizeof'
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, wr
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 writin
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
src/usr.
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 func.
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 a
"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 sof
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 src/share/man/m
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 poin
> 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 3
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 -G
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 do
"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 so
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:
>
> https://m
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 re
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 [-Werror,-Wimplic
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, sizeof(*n
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 exp
>> 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 the
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 gene
>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 r
On Wed, Feb 17, 2021 at 11:51:04PM +, David A. Holland wrote:
> Also, Someone(TM) should check if POSIX permits this or if we ought to
> improve the implementation.
Unsurprisingly, POSIX is silent. It just says "rewinddir shall also
cause the directory stream to refer to the current state of
In article <5912ca9e-b4e7-423d-a45d-f4693d1c9...@zoulas.com>,
Christos Zoulas wrote:
>-=-=-=-=-=-
Here's the final changes
- Make ALIGNED_POINTER use __alignof(t) instead of sizeof(t). This is more
correct because it works with non-primitive types and provides the ABI
alignment for the type
> On Feb 17, 2021, at 4:20 PM, Valery Ushakov wrote:
>
> On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote:
>
> This incrementally improves wrong things b/c you still have the "is
> aligned" and "ought to be aligned" conflated in one.
The incremental patch improves things and does
On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote:
> In article ,
> Valery Ushakov wrote:
>
> >But to get back to my main point, PLEASE, can we stop making random
> >aimless changes without prior discussion?
>
> Here's the change I'd like to make:
> - pass the alignment instead of
In article ,
Valery Ushakov wrote:
>But to get back to my main point, PLEASE, can we stop making random
>aimless changes without prior discussion?
Here's the change I'd like to make:
- pass the alignment instead of the mask (as Roy asked and to match the
other macro)
- use alignof to determin
Jared,
please test if the attached diff is sufficient.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
uvm_swap.c.diff
Description: Binary data
> On 17. Feb 2021, at 13:07, Jared McNeill wrote:
>
> I noticed this on reboot since this change:
>
> [ 3636.2891122] turning off
I noticed this on reboot since this change:
[ 3636.2891122] turning off swap...stopping swap on /swap failed with error 16
[ 3636.2991109] stopping swap on /swap2 failed with error 16
Can you have a look?
Thanks!
Jared
On Tue, 16 Feb 2021, Juergen Hannken-Illjes wrote:
Module Name:src
On Tue, Feb 16, 2021 at 18:51:43 -0500, Christos Zoulas wrote:
> On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote:
> -- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)
>
> | Well, it was you who did the definion of ALIGNED_POINTER centralized
> |
On Wed, Feb 17, 2021 at 00:51:03 +0100, Roland Illig wrote:
> 17.02.2021 00:25:10 Valery Ushakov :
> > On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
> >> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the
> >> test is for.
> >>
> >> I intentionally placed it between
On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)
| Well, it was you who did the definion of ALIGNED_POINTER centralized
| and overridable :)
|
| revision 1.400
| date: 2012-01-25 00:03:36 +0400; author: christos
17.02.2021 00:25:10 Valery Ushakov :
> On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
>> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the
>> test is for.
>>
>> I intentionally placed it between (which defines that
>> macro on x86 and some other platforms) and (whi
On 16.02.2021 23:32, Jason Thorpe wrote:
On Feb 16, 2021, at 1:56 PM, Roland Illig wrote:
A downside of this test is that the macro from gets only
evaluated at compile time of the test. The test therefore cannot cover
future updates to without being reinstalled itself. But
at least for th
On Tue, Feb 16, 2021 at 17:53:09 -0500, Christos Zoulas wrote:
> In this case "type" is a struct and we have __alignof() to handle
> it, but does this give the right answer?
>
> Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT and
> can be overriden (the opposite goes for POINTER_
On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
> On 16.02.2021 23:40, Valery Ushakov wrote:
> > On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
> >
> > > On 16.02.2021 19:46, Roy Marples wrote:
> > > > I suggest we change POINTER_ALIGNED_P to accept the alignment value we
On 16.02.2021 23:40, Valery Ushakov wrote:
On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
On 16.02.2021 19:46, Roy Marples wrote:
I suggest we change POINTER_ALIGNED_P to accept the alignment value we
want rather than the bitwise test we supply, like so:
#define POINTER_ALIGNED_P
In this case "type" is a struct and we have __alignof() to handle it, but does
this give the
right answer? Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT
and can be overriden (the opposite goes for POINTER_ALIGNED_P) I am all for
having one
macro, but how can we satisfy all the
On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
> On 16.02.2021 19:46, Roy Marples wrote:
> > I suggest we change POINTER_ALIGNED_P to accept the alignment value we
> > want rather than the bitwise test we supply, like so:
> >
> > #define POINTER_ALIGNED_P(p, a) (((uintptr_t)(p) & ((a
> On Feb 16, 2021, at 1:56 PM, Roland Illig wrote:
>
> A downside of this test is that the macro from gets only
> evaluated at compile time of the test. The test therefore cannot cover
> future updates to without being reinstalled itself. But
> at least for the release builds, it ensures a
On 16.02.2021 19:46, Roy Marples wrote:
I suggest we change POINTER_ALIGNED_P to accept the alignment value we
want rather than the bitwise test we supply, like so:
#define POINTER_ALIGNED_P(p, a) (((uintptr_t)(p) & ((a) - 1))
That's a good definition, clear, simple, obvious, without
Yes, I agree. I am going to change that.
christos
> On Feb 16, 2021, at 1:46 PM, Roy Marples wrote:
>
> Hi Christos
>
> On 14/02/2021 20:58, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Feb 14 20:58:35 UTC 2021
>> Modified Files:
>>
Hi Christos
On 14/02/2021 20:58, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun Feb 14 20:58:35 UTC 2021
Modified Files:
src/sys/net: if_arp.h if_bridge.c
src/sys/netinet: icmp_private.h if_arp.c igmp_var.h in_l2tp.c ip_flow.c
On Tue, Feb 16, 2021 at 09:29:15AM +, Roy Marples wrote:
> In my testing on aarch64 and octeon (both of which I think are strict
> alignment) neither need pullups nor copyups as the mbuf already has enough
> and arphrd is aligned correctly already.
Ah, we asserted too much alignment - indeed,
On 16/02/2021 09:20, Martin Husemann wrote:
On Tue, Feb 16, 2021 at 08:26:40AM +, Roy Marples wrote:
Is that because ARP_HDR_ALIGNMENT is forcing 4 byte alignment?
The KASSERT a few lines below triggerd, we need to be consistent.
For the purposes of using just the header we define I'm pr
On Tue, Feb 16, 2021 at 08:26:40AM +, Roy Marples wrote:
> Is that because ARP_HDR_ALIGNMENT is forcing 4 byte alignment?
The KASSERT a few lines below triggerd, we need to be consistent.
> For the purposes of using just the header we define I'm pretty sure we can
> use 2 byte alignment and s
On 16/02/2021 05:44, Martin Husemann wrote:
Module Name:src
Committed By: martin
Date: Tue Feb 16 05:44:14 UTC 2021
Modified Files:
src/sys/netinet: if_arp.c
Log Message:
Undo previous backout: alignment is needed here.
The reason for the previous backout was a misunders
On Sun, Feb 14, 2021 at 07:46:38PM +, Roy Marples wrote:
> On 13/02/2021 21:34, David Young wrote:
> > On Tue, Feb 09, 2021 at 07:02:32AM +, Roy Marples wrote:
> > > Hi David
> > >
> > > On 03/02/2021 21:45, David Young wrote:
> > > >
> > > > This change looks a little hasty to me.
> > >
On Mon, Feb 15, 2021 at 04:37:15PM +0100, Thomas Klausner wrote:
> Hi!
>
> Thanks for the man pages.
>
> There is none for uselocale(3), which is heavily referenced from
> these, nor do I find a prototype in /usr/include...
> so how does one use these? :)
We don't support uselocale. You use this
Hi!
Thanks for the man pages.
There is none for uselocale(3), which is heavily referenced from
these, nor do I find a prototype in /usr/include...
so how does one use these? :)
Thomas
On Mon, Feb 15, 2021 at 09:35:04AM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
>
901 - 1000 of 13240 matches
Mail list logo
