Thanks for fixing ...
On Sat, 7 Nov 2020, Christos Zoulas wrote:
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7
christos
On Nov 7, 2020, at 4:27 PM, Paul Goyette wrote:
OK, I think I found the problem, but I don't know how to solve it...
All of the undefined
> .if ${MACHINE_ARCH} == "arm"
this is wrong. it should use MACHINE_CPU.
.mrg.
/usr/obj/evbarm-earmv7/tools/bin/nbmake-evbarm -V MACHINE_ARCH
earmv7
christos
> On Nov 7, 2020, at 4:27 PM, Paul Goyette wrote:
>
> OK, I think I found the problem, but I don't know how to solve it...
>
> All of the undefined symbols are supposed to be provided by
>
>
OK, I think I found the problem, but I don't know how to solve it...
All of the undefined symbols are supposed to be provided by
.../sys/arch/arm/arm32/netbsd32_machdep.c
but there is no netbsd32_machdep.o included in the compat_netbsd32
module. This file should be included by the
On 2020/11/05 23:07, Paul Goyette wrote:
I will investigate.
Thanks!
Can you confirm that it works correctly if you have the built-in
module? (ie, kernel with ``options COMPAT_NETBSD32'')
Yes, it works fine.
rin
I will investigate.
Can you confirm that it works correctly if you have the built-in
module? (ie, kernel with ``options COMPAT_NETBSD32'')
On Thu, 5 Nov 2020, Rin Okuyama wrote:
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
On 2020/11/05 5:43, Paul Goyette wrote:
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then
On 2020/11/05 2:45, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine
BTW, the patch you submitted with the initial message in this thread
looks good for avoiding the issue. But I'm not sure it is a complete
solution.
In particular, you would need to build a 32-bit arm that contains ``no
options COMPAT_NETBSD32'' and then boot and load the compat_netbsd32
and
OK, this is my mistake. When I change the calls in the ptrace_common
modcmd, I should also have renamed the functions (including their
entries in sys/ptrace.h). I will commit this shortly, before I leave.
Thanks for the "recipe" for reproducing the problem - I will try it
later when I return.
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in
> On Nov 4, 2020, at 5:33 AM, Paul Goyette wrote:
>
> I guess I don't understand why a 32-bit architecture would also have
> COMPAT_NETBSD32.
In this particular case, it's for the old 32-bit ABI that predates the EABI
standard the ARM port now uses.
-- thorpej
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via
On 2020/11/04 22:31, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name: src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
On Wed, Nov 04, 2020 at 05:33:29AM -0800, Paul Goyette wrote:
> I guess I don't understand why a 32-bit architecture would also have
> COMPAT_NETBSD32.
(At least) mips and arm have various 32bit ABIs that are handled by
COMPAT_NETBSD32.
Martin
I guess I don't understand why a 32-bit architecture would also have
COMPAT_NETBSD32.
Christos, can you help out on this?
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hello again,
On 2020/11/02 3:51, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Nov 1
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't
Hello again,
On 2020/11/02 3:51, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Nov 1 18:51:03 UTC 2020
Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't use the ptrace module's
init/fini
On Sun, 1 Nov 2020, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Nov 1 18:51:03 UTC 2020
Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_core.c
src/sys/kern: compat_stub.c files.kern kern_core.c kern_sig.c
Hi Tobias,
> If you're interested there is an older version[1] of envctrl in the
> Attic that might be relevant to use for reference. It supported fan
> speed controls on E450. IIRC I got some of the magic constants from
> OpenSolaris. Sadly I don't own an E450 any more.
>
> [1]
>
On Sat, 24 Oct 2020 15:16:39 +
Julian Coleman wrote:
> Module Name: src
> Committed By: jdc
> Date: Sat Oct 24 15:16:39 UTC 2020
>
> Modified Files:
> src/sys/arch/sparc64/dev: pcf8591_envctrl.c
>
> Log Message:
> Add support for automatically changing the CPU fan speed on
Hi,
On 2020/10/21 15:42, Michael wrote:
Hello,
On Sun, 18 Oct 2020 11:54:21 +
"Rin Okuyama" wrote:
Module Name:src
Committed By: rin
Date: Sun Oct 18 11:54:21 UTC 2020
Modified Files:
src/sys/dev/wsfb: genfb.c
Log Message:
For WSDISPLAYIO_GET_FBINFO ioctl, set
Hello,
On Sun, 18 Oct 2020 11:54:21 +
"Rin Okuyama" wrote:
> Module Name: src
> Committed By: rin
> Date: Sun Oct 18 11:54:21 UTC 2020
>
> Modified Files:
> src/sys/dev/wsfb: genfb.c
>
> Log Message:
> For WSDISPLAYIO_GET_FBINFO ioctl, set WSFB_VRAM_IS_RAM to fbi_flags
>
This still isn't quite correct.
For i386, a custom kernel build fails. Here's the diff between GENERIC
and the custom config (this mirrors the config I used on amd64 to file
the original PR kern/55731):
--- GENERIC 2020-09-27 22:28:13.468056102 -0700
+++ TEST2020-10-20
I am getting errors, too, when I build a NOCOMPAT kernel:
# link NOCOMPAT/netbsd
/build/netbsd-compat/tools/x86_64/amd64/bin/x86_64--netbsd-ld -Map netbsd.map
--cref -T netbsd.ldscript -Ttext 0x8020 -e start -z
max-page-size=0x20 -X -o netbsd
Hi,
This causes build failures for LP64 archs without COMPAT_NETBSD32,
i.e., alpha and ie64:
kern_core.o: in function `coredump_modcmd':
(.text+0x1c4): undefined reference to `real_coredump_elf32
https://releng.netbsd.org/builds/HEAD/202010200300Z/
(Failure for aarch64eb is irrelevant, and
In article <20201019144701.a6d3bf...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Mon Oct 19 14:47:01 UTC 2020
>
>Modified Files:
> src/sys/kern: sys_ptrace.c sys_ptrace_common.c
>
>Log Message:
>Remove obsolete references
On 2020/10/18 21:18, Jared McNeill wrote:
I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you get
when you mmap the device. When shadow FB is used, that is generally only used
for rasops and mmap bypasses the shadow and uses device memory directly. So I
think this could
I think WSFB_VRAM_IS_RAM is meant to be a hint for what kind of memory you
get when you mmap the device. When shadow FB is used, that is generally
only used for rasops and mmap bypasses the shadow and uses device memory
directly. So I think this could cause performance regressions on such
On 2020/10/16 14:53, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Oct 16 05:53:40 UTC 2020
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Fixes a problem that the attach function reported
"wm_gmii_setup_phytype: Unknown PHY model.
On Tue, Oct 13, 2020 at 12:57:44PM +0200, Kamil Rytarowski wrote:
> > Log Message:
> > BE32 binaries are no longer supported for ARMv7 and later, and
> > therefore for aarch64eb.
> >
> > Reject them with ENOEXEC, rather than causing illegal instruction
> > exceptions due to unexpected binary
On 2020/10/13 19:57, Kamil Rytarowski wrote:
On 13.10.2020 09:04, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Oct 13 07:04:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: exec_machdep.c
Log Message:
BE32 binaries are no longer supported for
On 13.10.2020 09:04, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 13 07:04:49 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: exec_machdep.c
>
> Log Message:
> BE32 binaries are no longer supported for ARMv7 and later, and
> therefore for
Hello,
On Sun, 11 Oct 2020 21:41:57 +
"Julian Coleman" wrote:
> Module Name: src
> Committed By: jdc
> Date: Sun Oct 11 21:41:57 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: radeonfb.c
>
> Log Message:
...
> don't ignore the bottom 200 lines of the display (for no
On Mon, 07 Sep 2020 at 20:47:25 +1000, matthew green wrote:
"Jason R Thorpe" writes:
Module Name:src
Committed By: thorpej
Date: Mon Sep 7 03:50:41 UTC 2020
Modified Files:
src/sys/kern: files.kern init_main.c
Log Message:
Add the ability to set an alternate cnmagic
Thank you very much!
Thomas
> On 06.10.2020, at 15:42, Christos Zoulas wrote:
>
> Module Name: src
> Committed By: christos
> Date: Tue Oct 6 13:42:03 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/include: vmparam.h
> src/sys/arch/amd64/include: vmparam.h
>
It works fine now. Thank you for quick fix!!
rin
On 2020/10/06 15:28, Nick Hudson wrote:
On 06/10/2020 01:54, Rin Okuyama wrote:
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
On 06/10/2020 01:54, Rin Okuyama wrote:
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S
Log Message:
Move el[01]_trap_exit into vectors.S
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S
Log Message:
Move el[01]_trap_exit into vectors.S where the callers exist
To generate
On 2020/10/02 22:42, Jonathan A. Kollasch wrote:
On Sun, Jul 21, 2019 at 03:57:24PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun Jul 21 15:57:24 UTC 2019
Modified Files:
src/sys/dev/fdt: dw_apb_uart.c
Log Message:
The device cannot recognize
On Sun, Jul 21, 2019 at 03:57:24PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun Jul 21 15:57:24 UTC 2019
>
> Modified Files:
> src/sys/dev/fdt: dw_apb_uart.c
>
> Log Message:
> The device cannot recognize break signal. Use + (five plus signs) as
>> Index: src/sys/arch/aarch64/include/cpu.h
>> diff -u src/sys/arch/aarch64/include/cpu.h:1.27 src/sys/arch/aarch64/inc=
>lude/cpu.h:1.28
>> --- src/sys/arch/aarch64/include/cpu.h:1.27 Mon Sep 14 10:06:35 2020
>> +++ src/sys/arch/aarch64/include/cpu.h Thu Oct 1 06:40:16 2020
>> @@ -1,4
On 01/10/2020 07:40, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Thu Oct 1 06:40:16 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: procfs_machdep.c
src/sys/arch/aarch64/include: cpu.h
Log Message:
fix build error with LLVM
[...]
Index:
>On 24/09/2020 10:04, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Thu Sep 24 09:04:38 UTC 2020
>>
>> Modified Files:
>> src/sys/arch/aarch64/aarch64: bus_space_asm_generic.S
>>
>> Log Message:
>> fix bugs in *_bs_rm_8_swap(). it was only
On 24/09/2020 10:04, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Thu Sep 24 09:04:38 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: bus_space_asm_generic.S
Log Message:
fix bugs in *_bs_rm_8_swap(). it was only reading 4 bytes, not 8 bytes.
I
Hi,
Chuck Silvers writes:
> On Tue, Sep 22, 2020 at 01:51:33AM +0900, Ryo ONODERA wrote:
>> Hi,
>>
>> It seems that r1.124 of uvm_amap.c causes random userland segfaults
>> on my NetBSD/amd64.
>
> this should be fixed now, could you try again?
>
> this was another case of my usual trick "test
On Tue, Sep 22, 2020 at 01:51:33AM +0900, Ryo ONODERA wrote:
> Hi,
>
> It seems that r1.124 of uvm_amap.c causes random userland segfaults
> on my NetBSD/amd64.
this should be fixed now, could you try again?
this was another case of my usual trick "test a change well, modify
the change at the
Hi,
It seems that r1.124 of uvm_amap.c causes random userland segfaults
on my NetBSD/amd64.
If you cannot reproduce the random segfaults, I will send my backtraces.
"Chuck Silvers" writes:
> Module Name: src
> Committed By: chs
> Date: Sun Sep 20 23:03:01 UTC 2020
>
> Modified Files:
I don't think this should be reverted, because LUN 0 must exist, but if
there is no device on it, it will report "NOT PRESENT". We do not want
the scan to stop in this case, but it should continue with other LUNs
(such as those found through REPORT LUNS in the future).
Kind regards,
+ Kimmo
On
On 11.09.2020 17:16, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Fri Sep 11 15:16:00 UTC 2020
>
> Modified Files:
> src/sys/net: if_llatbl.c
> src/sys/netinet: if_arp.c if_inarp.h tcp_input.c
>
> Log Message:
> ARP: Use ND rather than our own.
>
> This
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Mon Sep 7 03:50:41 UTC 2020
>
> Modified Files:
> src/sys/kern: files.kern init_main.c
>
> Log Message:
> Add the ability to set an alternate cnmagic in the kernel config
> file, e.g.:
>
> options
> On Sep 3, 2020, at 1:14 PM, matthew green wrote:
>
> "Jason R Thorpe" writes:
>> Module Name: src
>> Committed By:thorpej
>> Date:Thu Sep 3 04:20:54 UTC 2020
>>
>> Modified Files:
>> src/sys/arch/alpha/include: cpu.h
>>
>> Log Message:
>> Garabage-collect
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Thu Sep 3 04:20:54 UTC 2020
>
> Modified Files:
> src/sys/arch/alpha/include: cpu.h
>
> Log Message:
> Garabage-collect curpcb / cpu_info::ci_curpcb.
does alpha have modules? this may be a ABI change
Hi Martin !
That is strange - I didn't expect that, especially as the previous code
was wrong with respect to state tracking.
Can you check whether the addresses do not have the DEtACHED flag?
You could try the dtrace script from the PR - it shows a little bit what
is going on.
There was also
On Mon, Aug 24, 2020 at 12:46:04PM +, Frank Kardel wrote:
> Module Name: src
> Committed By: kardel
> Date: Mon Aug 24 12:46:04 UTC 2020
>
> Modified Files:
> src/sys/dev/mii: mii_physubr.c
>
> Log Message:
> Keep the change check invariant intact. The previous code could miss
> Modified Files:
> src/sys/uvm/pmap: pmap_segtab.c
>
> Log Message:
> Remove the #if defined(__mips_n64) && PAGE_SIZE == 8192 and make the
> check MI - all PTs are PAGE_SIZE aligned
thanks! that is a much better way of doing it.
.mrg.
On 2020/08/11 10:24, matthew green wrote:
XXX
Apply similar fixes to other m68k ports.
yes...but also, a long-term project to consolidate all the
almost-identical m68k code copied into each port would
avoid this probably :-)
Agreed. Also, I've found many dead codes in amiga/locore.s.
I'd
On Sat, Aug 15, 2020 at 01:20:48AM +0900, Ryo ONODERA wrote:
> Hi,
>
> "Chuck Silvers" writes:
>
> > Module Name:src
> > Committed By: chs
> > Date: Fri Aug 14 09:06:15 UTC 2020
> >
> > Modified Files:
> > src/sys/miscfs/genfs: genfs_io.c
> > src/sys/uvm:
Hi,
"Chuck Silvers" writes:
> Module Name: src
> Committed By: chs
> Date: Fri Aug 14 09:06:15 UTC 2020
>
> Modified Files:
> src/sys/miscfs/genfs: genfs_io.c
> src/sys/uvm: uvm_extern.h uvm_object.c uvm_object.h uvm_page.c
> uvm_page_status.c uvm_pager.c
matthew green wrote:
>however, i'm looking at the changes and i'm not 100% convinced
>it's safe to simply replace this file as-is.
>
> - struct v4l2_pix_format is laid out differently
> - enum v4l2_buf_type <-> u_int32_t does not seem safe, in
> eg struct v4l2_buffer. i *think* it may be,
matthew green writes:
> > also, these updates to video(4) don't require a kernel bump
> > so please revert that too.
>
> but this part could be done if you do it fast..
uvideo(4) as a module proves me wrong about this one too..
however, i'm looking at the changes and i'm not 100% convinced
it's
matthew green wrote:
>"Robert Swindells" writes:
>> Module Name: src
>> Committed By:rjs
>> Date:Mon Aug 10 19:27:28 UTC 2020
>>
>> Modified Files:
>> src/sys/dev: video.c
>> src/sys/dev/usb: uvideo.c
>> src/sys/sys: videoio.h
>>
>> Log Message:
>> Add
> > Import sys/videoio.h from OpenBSD, this is just the Linux headers
> > concatenated together.
>
> this seems very problematic in that you've added GPLv2 code
> into src/sys/sys.
>
> please revert.
ah- i see it has dual-license, please ignore me. thanks
to nia@ for the hint..
> also, these
"Robert Swindells" writes:
> Module Name: src
> Committed By: rjs
> Date: Mon Aug 10 19:27:28 UTC 2020
>
> Modified Files:
> src/sys/dev: video.c
> src/sys/dev/usb: uvideo.c
> src/sys/sys: videoio.h
>
> Log Message:
> Add some extra V4L ioctl() requests to latest V4L
thanks!
> XXX
> Apply similar fixes to other m68k ports.
yes...but also, a long-term project to consolidate all the
almost-identical m68k code copied into each port would
avoid this probably :-)
Hi,
Sorry for the serious delay in my response.
On 2020/07/22 13:37, matthew green wrote:
thanks for getting more m68k working!
Thanks!
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Tue Jul 21 06:39:31 UTC 2020
Modified Files:
On Tue, Aug 04, 2020 at 07:12:54 +0300, Valery Ushakov wrote:
> On Tue, Aug 04, 2020 at 12:50:11 +0900, SAITOH Masanobu wrote:
>
> > On 2020/08/03 23:00, Valeriy E. Ushakov wrote:
> > > Module Name: src
> > > Committed By: uwe
> > > Date: Mon Aug 3 14:00:41 UTC 2020
> > >
On 2020/08/04 12:50, SAITOH Masanobu wrote:
Hi.
On 2020/08/03 23:00, Valeriy E. Ushakov wrote:
Module Name: src
Committed By: uwe
Date: Mon Aug 3 14:00:41 UTC 2020
Modified Files:
src/sys/dev/mii: miidevs_data.h
Log Message:
mii_knowndevs[] is de facto const, define it as
On Mon, Aug 03, 2020 at 02:31:11PM -0700, Tom Spindler (moof) wrote:
> On Mon, Aug 03, 2020 at 10:59:04PM +0200, Herbert J. Skuhra wrote:
> > This breaks the build (amd64) on FreeBSD and GNU/Linux:
> >
> > aslcompilerlex.l: In function 'AslCompilerlex':
> > aslcompilerlex.l:589:22: error:
On Tue, Aug 04, 2020 at 12:50:11 +0900, SAITOH Masanobu wrote:
> On 2020/08/03 23:00, Valeriy E. Ushakov wrote:
> > Module Name:src
> > Committed By: uwe
> > Date: Mon Aug 3 14:00:41 UTC 2020
> >
> > Modified Files:
> > src/sys/dev/mii: miidevs_data.h
> >
> >
Hi.
On 2020/08/03 23:00, Valeriy E. Ushakov wrote:
Module Name:src
Committed By: uwe
Date: Mon Aug 3 14:00:41 UTC 2020
Modified Files:
src/sys/dev/mii: miidevs_data.h
Log Message:
mii_knowndevs[] is de facto const, define it as such.
To generate a diff of this
On Mon, Aug 03, 2020 at 10:59:04PM +0200, Herbert J. Skuhra wrote:
> This breaks the build (amd64) on FreeBSD and GNU/Linux:
>
> aslcompilerlex.l: In function 'AslCompilerlex':
> aslcompilerlex.l:589:22: error: 'PARSEOP_REGIONSPACE_PRM' undeclared (first
> use in this function); did you mean
On Sun, 02 Aug 2020 22:25:55 +0200, "Christos Zoulas" wrote:
>
> Module Name: src
> Committed By: christos
> Date: Sun Aug 2 20:25:55 UTC 2020
>
> Modified Files:
> src/sys/external/bsd/acpica/dist/compiler: aslcompiler.l aslerror.c
> aslload.c aslxref.c
>
On 02.08.2020 17:50, Taylor R Campbell wrote:
>> Date: Sun, 2 Aug 2020 17:35:06 +0200
>> From: Kamil Rytarowski
>>
>> On 02.08.2020 16:44, Taylor R Campbell wrote:
Date: Sun, 2 Aug 2020 16:04:15 +0200
From: Kamil Rytarowski
On 02.08.2020 15:57, Taylor R Campbell wrote:
>
> Date: Sun, 2 Aug 2020 17:35:06 +0200
> From: Kamil Rytarowski
>
> On 02.08.2020 16:44, Taylor R Campbell wrote:
> >> Date: Sun, 2 Aug 2020 16:04:15 +0200
> >> From: Kamil Rytarowski
> >>
> >> On 02.08.2020 15:57, Taylor R Campbell wrote:
> >>> But it sounds like the original motivation is
On 02.08.2020 16:44, Taylor R Campbell wrote:
>> Date: Sun, 2 Aug 2020 16:04:15 +0200
>> From: Kamil Rytarowski
>>
>> On 02.08.2020 15:57, Taylor R Campbell wrote:
>>> But it sounds like the original motivation is that it triggered
>>> -Wvla...which frankly strikes me as a compiler bug since
Le dim. 2 août 2020 à 15:57, Taylor R Campbell
a écrit :
> Why does it improve readability?
Certainly using cringe language features does not help readability.
> What else does -Wvla choke on in src/sys?
Some drm drivers, and uvm, particularly uvm_bio.c. I'd like to work
towards enabling -Wvla
> Date: Sun, 2 Aug 2020 16:04:15 +0200
> From: Kamil Rytarowski
>
> On 02.08.2020 15:57, Taylor R Campbell wrote:
> > But it sounds like the original motivation is that it triggered
> > -Wvla...which frankly strikes me as a compiler bug since there's
> > obviously no actual VLA created in
On Sun, Aug 02, 2020 at 01:57:11PM +, Taylor R Campbell wrote:
> But it sounds like the original motivation is that it triggered
> -Wvla...which frankly strikes me as a compiler bug since there's
> obviously no actual VLA created in sizeof; as far as I can tell
> there's no semantic difference
On 02.08.2020 16:25, Paul Goyette wrote:
> On Sun, 2 Aug 2020, Kamil Rytarowski wrote:
>
>> On 02.08.2020 15:57, Taylor R Campbell wrote:
>>> But it sounds like the original motivation is that it triggered
>>> -Wvla...which frankly strikes me as a compiler bug since there's
>>> obviously no
On Sun, 2 Aug 2020, Kamil Rytarowski wrote:
On 02.08.2020 15:57, Taylor R Campbell wrote:
But it sounds like the original motivation is that it triggered
-Wvla...which frankly strikes me as a compiler bug since there's
obviously no actual VLA created in sizeof; as far as I can tell
there's no
On 02.08.2020 15:57, Taylor R Campbell wrote:
> But it sounds like the original motivation is that it triggered
> -Wvla...which frankly strikes me as a compiler bug since there's
> obviously no actual VLA created in sizeof; as far as I can tell
> there's no semantic difference between
> Date: Sun, 2 Aug 2020 10:47:21 +0200
> From: Jarom�r Dole ek
>
> Readability first and foremost in this case.
>
> I was exploring if I can disable VLAs for the kernel altogether, this
> can't be done for now. Nevertheless, this change looked like it would
> be useful to make anyway.
Why does
Readability first and foremost in this case.
I was exploring if I can disable VLAs for the kernel altogether, this
can't be done for now. Nevertheless, this change looked like it would
be useful to make anyway.
Le dim. 2 août 2020 à 01:15, Taylor R Campbell
a écrit :
>
> > Module Name:src
>
> Module Name:src
> Committed By: jdolecek
> Date: Sat Aug 1 12:36:36 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/pci: pci_intr_machdep.c
> src/sys/arch/x86/x86: mainbus.c
>
> Log Message:
> reorder includes to pull __HAVE_PCI_MSI_MSIX properly via
>
If
> Module Name:src
> Committed By: jdolecek
> Date: Sat Aug 1 11:18:26 UTC 2020
>
> Modified Files:
> src/sys/kern: subr_autoconf.c
>
> Log Message:
> avoid VLA for the sizeof() calculations
Why?
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Tue Jul 28 09:36:05 UTC 2020
>
> Modified Files:
> src/sys/dev/ic: nvmevar.h
> src/sys/dev/pci: nvme_pci.c
>
> Log Message:
> add a quirk to disable MSI, and enable it for Intel SSD DC P4500
>
>
On 27/07/2020 21:44, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Mon Jul 27 20:44:30 UTC 2020
Modified Files:
src/sys/crypto/aes: aes_ccm.c aes_ccm.h
Log Message:
Gather auth[16] and ctr[16] into one authctr[32].
Should appease clang.
clang
thanks for getting more m68k working!
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Jul 21 06:39:31 UTC 2020
>
> Modified Files:
> src/sys/arch/amiga/amiga: locore.s
>
> Log Message:
> Align tmpstk to 4-byte boundary in the same manner as mac68k.
>
>
On 2020/07/18 17:30, Jukka Ruohonen wrote:
On Sat, Jul 18, 2020 at 05:19:07PM +0900, Rin Okuyama wrote:
For most (all?) ports, these specifiers are exposed only for
_KERNEL and friends. So, inttypes(*3*) would not be the best
place for them. Currently, I'm not sure where they should be.
On Sat, Jul 18, 2020 at 05:19:07PM +0900, Rin Okuyama wrote:
> For most (all?) ports, these specifiers are exposed only for
> _KERNEL and friends. So, inttypes(*3*) would not be the best
> place for them. Currently, I'm not sure where they should be.
> /usr/share/misc/style?
Perhaps a new
On 2020/07/16 16:02, matthew green wrote:
thanks! i'll try to remember we have PRIxPADDR because i
considered looking for it and thought we didn't have it...
My pleasure!
On 2020/07/16 16:10, Jukka Ruohonen wrote:
The whole { PRIxPADDR, PRIxPSIZE, ..., PRIxREGISTER } family
should probably
Le 28/04/2020 à 09:16, Luke Mewburn a écrit :
On 20-04-26 18:15, Maxime Villard wrote:
| - There was no demonstrated use-case justifying importing it. In addition,
|major OSes like Windows and macOS do not implement SCTP. There just is
no
|demand for SCTP on the market; and on
One of the things which need to be done is calling the if_ioctl always
with the IFNET_LOCK() held. Right now it sometimes is, and other times
it is not, so it's not possible to rely on it and KASSERT().
As for bnx(4) I did just some basic fixes around making it work with
MSI(-X), since I don't
> On Jul 17, 2020, at 3:50 PM, matthew green wrote:
>
> any chance you can look at NET_MPSAFE here etc? :)
I have a bunch of local changes for this in one of my trees, and I hope to get
back to it after netbsd-10 branches.
-- thorpej
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Fri Jul 17 09:48:21 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: if_bnx.c
>
> Log Message:
> re-enable MSI/MSI-X, the TX timeouts were caused by the IFF_OACTIVE handling,
> which was fixed in previous
On Thu, Jul 16, 2020 at 05:02:18PM +1000, matthew green wrote:
> thanks! i'll try to remember we have PRIxPADDR because i
> considered looking for it and thought we didn't have it...
The whole { PRIxPADDR, PRIxPSIZE, ..., PRIxREGISTER } family
should probably be documented in inttypes(3)?
-
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Wed Jul 15 15:08:26 UTC 2020
>
> Modified Files:
> src/sys/uvm: uvm_physseg.c
>
> Log Message:
> Fix typo. Use PRIxPADDR rather than casting.
thanks! i'll try to remember we have PRIxPADDR because i
considered
401 - 500 of 5582 matches
Mail list logo
