Re: CVS commit: src/dist/pf/usr.sbin/ftp-proxy
There’s npf interface in ftp-proxy. What if we want to use ftp-proxy with npf. So then we would have to separate ftp-proxy from pf into its own module for maintainability ?? > On 22 Jan 2025, at 1:01 PM, Christoph Badura wrote: > > On Tue, Jan 07, 2025 at 09:15:41PM +, Emmanuel wrote: >> Modified Files: >> src/dist/pf/usr.sbin/ftp-proxy: filter.c ftp-proxy.c >> Log Message: >> clearn up : remove trailing whitespaces > > I think we don't generally do whitespace or style cleanups in source > code imported from external projects. That just makes merging updates > more difficult. > > Admittedly, importing a new version of pf is unlikely. So I would leave > these commits as is. > > --chris Emmanuel
Re: CVS commit: src/dist/pf/usr.sbin/ftp-proxy
On Tue, Jan 07, 2025 at 09:15:41PM +, Emmanuel wrote: > Modified Files: > src/dist/pf/usr.sbin/ftp-proxy: filter.c ftp-proxy.c > Log Message: > clearn up : remove trailing whitespaces I think we don't generally do whitespace or style cleanups in source code imported from external projects. That just makes merging updates more difficult. Admittedly, importing a new version of pf is unlikely. So I would leave these commits as is. --chris
Re: CVS commit: src/external/lgpl2/userspace-rcu/dist/include/urcu
In article <6148.1737238...@splode.eterna23.net>, matthew green wrote: >> src/external/lgpl2/userspace-rcu/dist/include/urcu/arch: sparc64.h > >hmmm, you could make the ones with "stbar" also be present for >v7 as it is a no-op there... and if binutils is to be believed, >ldstub also exists in sparc v6 (!). > >perhaps "swap" isntruction (which is in v7) can be used here? > >either way, please make this consistent for v7 and v8, as we >compile with v7 target normally and so this actually means that >v8 systems are missing the support entirely. > Ok, I will do it unconditionally then. I was just doing what the gcc code was doing before (as mentioned in the comment). christos
re: CVS commit: src/external/lgpl2/userspace-rcu/dist/include/urcu
> src/external/lgpl2/userspace-rcu/dist/include/urcu/arch: sparc64.h hmmm, you could make the ones with "stbar" also be present for v7 as it is a no-op there... and if binutils is to be believed, ldstub also exists in sparc v6 (!). perhaps "swap" isntruction (which is in v7) can be used here? either way, please make this consistent for v7 and v8, as we compile with v7 target normally and so this actually means that v8 systems are missing the support entirely. thanks. .mrg.
Re: CVS commit: src/distrib/common/bootimage
mrg@ wrote: > > FAT (for ESP) is always LE so "-B endian" for makefs(8) is not necessary. > > > > (not sure if there is any "EFI on big endian CPU" system though) > > EFI runs in little-endian always, but efiboot can load a big > endian kernel and run it properly. this is how we boot > big-endian on systems like rockpro64 (or some arm32 ones.) Ah, indeed EFI boot image works on qemu-system-arm -M virt: --- % qemu-system-arm -m 1024 -nographic -drive file=NetBSD-10.1-evbarm.img,media=disk,format=raw,index=0,if=none,id=disk -device virtio-blk-device,drive=disk -netdev user,ipv6=off,id=net,hostfwd=tcp::10022-:22 -device virtio-net-device,netdev=net -M virt -bios QEMU_EFI.fd -cpu cortex-a15 BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x1,0x0) BdsDxe: starting Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x1,0x0) \\-__,--,___. \\__,---` NetBSD/evbarm efiboot (arm) \\ `---,_. Revision 2.13 (Mon Dec 16 13:08:11 UTC 2024) \\-,_,.---` \\ \\ \\ Press return to boot now, any other key for boot prompt booting netbsd - starting in 0 seconds. 7842484+2512736+1403040 [468930+549232+597339]=0xcc6dd0 [ 1.000] NetBSD/evbarm (fdt) booting ... [ 1.000] [ Kernel symbol table missing! ] [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, [ 1.000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, [ 1.000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, [ 1.000] 2024 [ 1.000] The NetBSD Foundation, Inc. All rights reserved. [ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000] The Regents of the University of California. All rights reserved. [ 1.000] NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024 [ 1.000] mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/GENERIC [ 1.000] total memory = 1024 MB [ 1.000] avail memory = 984 MB [ 1.000] armfdt0 (root) [ 1.000] simplebus0 at armfdt0: linux,dummy-virt [ 1.000] cpus0 at simplebus0 [ 1.000] simplebus1 at simplebus0 [ 1.000] simplebus2 at simplebus0 [ 1.000] cpu0 at cpus0: Cortex-A15 r4p0 (Cortex V7A core) [ 1.000] cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled [ 1.000] cpu0: L1 32KB/64B 2-way (256 set) PIPT Instruction cache [ 1.000] cpu0: L1 32KB/64B 2-way (256 set) write-back-locking-C PIPT Data cache [ 1.000] cpu0: L2 2304KB/64B 16-way (2304 set) write-through PIPT Unified cache [ 1.000] vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals [ 1.000] fclock0 at simplebus0: 2400 Hz fixed clock (clk24mhz) [ 1.000] gic0 at simplebus0: GIC [ 1.000] armgic0 at gic0: Generic Interrupt Controller, 288 sources (288 valid) [ 1.000] armgic0: 256 Priorities, 256 SPIs, 16 PPIs, 16 SGIs [ 1.000] armgic0: GICv2m @ 0x802, SPIs 80-143 [ 1.000] gtmr0 at simplebus0: Generic Timer [ 1.000] gtmr0: interrupting on GIC irq 27 [ 1.000] armgtmr0 at gtmr0: Generic Timer (62500 kHz, virtual) [ 1.040] plcom0 at simplebus0: ARM PL011 UART [ 1.040] plcom0: txfifo disabled [ 1.040] plcom0: console [ 1.040] plcom0: interrupting on GIC irq 33 [ 1.040] plgpio0 at simplebus0: GPIO [ 1.040] gpio0 at plgpio0: 8 pins [ 1.040] psci0 at simplebus0: PSCI 1.1 [ 1.040] qemufwcfg0 at simplebus0 [ 1.040] virtio0 at simplebus0 [ 1.040] virtio1 at simplebus0 [ 1.040] virtio2 at simplebus0 [ 1.040] virtio3 at simplebus0 [ 1.040] virtio4 at simplebus0 [ 1.040] virtio5 at simplebus0 [ 1.040] virtio6 at simplebus0 [ 1.040] virtio7 at simplebus0 [ 1.040] virtio8 at simplebus0 [ 1.040] virtio9 at simplebus0 [ 1.040] virtio10 at simplebus0 [ 1.040] virtio11 at simplebus0 [ 1.040] virtio12 at simplebus0 [ 1.040] virtio13 at simplebus0 [ 1.040] virtio14 at simplebus0 [ 1.040] virtio15 at simplebus0 [ 1.040] virtio16 at simplebus0 [ 1.040] virtio17 at simplebus0 [ 1.040] virtio18 at simplebus0 [ 1.040] virtio19 at simplebus0 [ 1.040] virtio20 at simplebus0 [ 1.040] virtio21 at simplebus0 [ 1.040] virtio22 at simplebus0 [ 1.040] virtio23 at simplebus0 [ 1.040] virtio24 at simplebus0 [ 1.040] virtio25 at simplebus0 [ 1.040] virtio26 at simplebus0 [ 1.040] virtio27 at simplebus0 [ 1.040] virtio28 at simplebus0 [ 1.040] virtio29 at simplebus0 [ 1.040] virtio30 at simplebus0 [ 1.040] virtio30: network device (id 1, rev. 0x01) [ 1.040] vioif0 at virtio30: features: 0x31870020 [ 1.040] vioif0: Ethernet address 52:54:00:12:34:56 [ 1.040] virtio30
re: CVS commit: src/distrib/common/bootimage
> FAT (for ESP) is always LE so "-B endian" for makefs(8) is not necessary. > > (not sure if there is any "EFI on big endian CPU" system though) EFI runs in little-endian always, but efiboot can load a big endian kernel and run it properly. this is how we boot big-endian on systems like rockpro64 (or some arm32 ones.) acpica doesn't work properly in big-endian mode, though they do have some #if'd that are supposed to work, so it only works in FDT mode... .mrg.
Re: CVS commit: src/etc/pam.d
> On Dec 31, 2024, at 5:05 PM, Julio Merino wrote: > > On Tue, Dec 31, 2024 at 03:27:49PM -0500, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Tue Dec 31 20:27:49 UTC 2024 >> >> Modified Files: >> src/etc/pam.d: Makefile >> >> Log Message: >> Use a suffix rule. > > Thanks for this. I suppose this fixes the problem that someone else > mentioned that caused my change to pollute the source tree :( ? > >> I would have just commented out the skey entry instead, >> since it is rarely used and we already do that for kerberos. We could now >> use MKKERBEROS to enable it by default, since we have the machinery... > > I thought about doing this for pam_krb5 as well, but note a commit > from June 20th of 2023 to that directory that intentionally commented > those lines out even with MKKERBEROS=yes. Not sure it's a good idea > to do it. > > Happy new year! Happy New Year! Matt fixed the problem by adding pam.d to the SUBDIRs in the Makefile above. Yes, we should fix https://gnats.netbsd.org/57470 before enabling kerberos by default. christos signature.asc Description: Message signed with OpenPGP
re: CVS commit: src/etc/pam.d
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Tue Dec 31 20:27:49 UTC 2024 > > Modified Files: > src/etc/pam.d: Makefile > > Log Message: > Use a suffix rule. I would have just commented out the skey entry instead, > since it is rarely used and we already do that for kerberos. We could now > use MKKERBEROS to enable it by default, since we have the machinery... unfortunately, this doesn't help. etc/pam.d subdir is not in SUBDIR so it is not entered during 'make obj' phase, so anything in here is not working in an objdir, and the build still fails due to writing to the src dir. .mrg.
Re: CVS commit: src/etc/pam.d
On Tue, Dec 31, 2024 at 03:27:49PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Tue Dec 31 20:27:49 UTC 2024 > > Modified Files: > src/etc/pam.d: Makefile > > Log Message: > Use a suffix rule. Thanks for this. I suppose this fixes the problem that someone else mentioned that caused my change to pollute the source tree :( ? > I would have just commented out the skey entry instead, > since it is rarely used and we already do that for kerberos. We could now > use MKKERBEROS to enable it by default, since we have the machinery... I thought about doing this for pam_krb5 as well, but note a commit from June 20th of 2023 to that directory that intentionally commented those lines out even with MKKERBEROS=yes. Not sure it's a good idea to do it. Happy new year!
Re: CVS commit: src/usr.sbin/altq/libaltq
On Tue, Dec 24, 2024 at 9:13 PM Robert Elz wrote: > > Module Name:src > Committed By: kre > Date: Tue Dec 24 12:13:05 UTC 2024 > > Modified Files: > src/usr.sbin/altq/libaltq: altq_qop.h > > Log Message: > Make return type in prototype for atobps() match that of the declaration. > Hopefully fix 32 bit builds. Oops. Thank you for the fix! ozaki-r > > > > To generate a diff of this commit: > cvs rdiff -u -r1.9 -r1.10 src/usr.sbin/altq/libaltq/altq_qop.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/sys/arch/sun3/dev
riastradh@ wrote: > > Modified Files: > > src/sys/arch/sun3/dev: bw2.c cg2.c cg4.c fb.c fd.c kd.c xd.c xy.c > > > > Log Message: > > Make local dev_type_*() functions static. > > While you're doing this kind of cleanup, maybe you could also change > > static dev_type_open(foo_open); > > to > > static dev_open_t foo_open; > > so we have less unnecessary macro magic for forward declarations. Well, there are so many existing MI implementations so maybe we need major cleanup? --- % grep -R 'static dev_type' sys/dev | wc -l 352 % grep -R 'static dev_type' sys/dev sys/dev/acpi/acpi_dev.c:static dev_type_read(acpi_read); sys/dev/ccd.c:static dev_type_open(ccdopen); sys/dev/ccd.c:static dev_type_close(ccdclose); sys/dev/ccd.c:static dev_type_read(ccdread); sys/dev/ccd.c:static dev_type_write(ccdwrite); sys/dev/ccd.c:static dev_type_ioctl(ccdioctl); sys/dev/ccd.c:static dev_type_strategy(ccdstrategy); sys/dev/ccd.c:static dev_type_size(ccdsize); sys/dev/cgd.c:static dev_type_open(cgdopen); sys/dev/cgd.c:static dev_type_close(cgdclose); sys/dev/cgd.c:static dev_type_read(cgdread); sys/dev/cgd.c:static dev_type_write(cgdwrite); sys/dev/cgd.c:static dev_type_ioctl(cgdioctl); sys/dev/cgd.c:static dev_type_strategy(cgdstrategy); sys/dev/cgd.c:static dev_type_dump(cgddump); sys/dev/cgd.c:static dev_type_size(cgdsize); sys/dev/efi.c:static dev_type_open(efi_open); sys/dev/efi.c:static dev_type_close(efi_close); sys/dev/efi.c:static dev_type_ioctl(efi_ioctl); : --- > (This is all the dev_type_* macros expand to; there's really no need > for them -- and using them is longer than their expansion!) Note for cons(9) has actually function declarations, unlike (not sure if there were historical reasons): --- /* console-specific types */ #define dev_type_cnprobe(n) void n(struct consdev *) #define dev_type_cninit(n) void n(struct consdev *) #define dev_type_cngetc(n) int n(dev_t) #define dev_type_cnputc(n) void n(dev_t, int) #define dev_type_cnpollc(n) void n(dev_t, int) #define dev_type_cnbell(n) void n(dev_t, u_int, u_int, u_int) #define dev_type_cnhalt(n) void n(dev_t) #define dev_type_cnflush(n) void n(dev_t) --- Izumi Tsutsui
Re: CVS commit: src
Date:Sun, 22 Dec 2024 14:23:19 +
From:Taylor R Campbell
Message-ID: <20241222142323.de3fc84...@mail.netbsd.org>
| but I find the syntax of `local x=y' syntax to be a sharp edge
| because it works differently from `x=y'.
It does indeed, and you're right, those quotes probably should not
have been removed. I will fix them.
POSIX is (stupidly I think, though there are reasons) partly fixing
that in the latest version (not that it directly affects "local" as
that isn't in POSIX .. not enough shells agree on how it really works)
by adding the notion of "declaration utilities". In those (export,
readonly, and by analogy, anything similar, like local) the args are
parsed as if they were var-assigns (any args that look like one).
I think it is unnecessary, and have no plans to go anywhere near that
(it breaks the way the shell works in general), but it would fix this
particular issue.
| So I think it is better style in shell scripts to either consistently
| write
|
| local x="$1"
|
| with the quotes, or separate the local and the assignment:
|
| local x
|
| x=$1
Not consistently, there are times when one is better than the other,
for various possible reasons, but in general, using one of those is
the right way.
| (That said, I agree that the inner quotes in "${2-"$1"}" were silly
| and replacing it by local result="${2-$1}" is fine.)
Not just silly, simply wrong. In that (the original) the $1 is actually
unquoted. In those old original 4 ${varXword} operators (X = '-' '+' '=' or
'?') the quoting rules (derived from Bourne's original pdp-11 implementation,
where code space was at a premium) the " chars simply operate in pairs.
Almost no-one can believe this, and people get it wrong all the time.
In the previous standard, POSIX required that inside the {} any quotes
were at least paired, to avoid stuff like "${1"-word} which Bourne's shell
allowed, but in the latest version what all this might mean has just been
made unspecified, which paves the way for shells (given sufficient time for
old code to mostly go away) to change the rules and allow a new quoting
context inside the {} (just as is done for the substring match operators,
and in shells that provide more operators, all of them as well).
I'm not sure it is actually possible to reasonably change the meaning
however, too much (currently correctly written) would become unquoted,
and potentially wrong.
kre
Re: CVS commit: src/sys/arch/sun3/dev
> Module Name:src > Committed By: tsutsui > Date: Sat Dec 21 17:40:11 UTC 2024 > > Modified Files: > src/sys/arch/sun3/dev: bw2.c cg2.c cg4.c fb.c fd.c kd.c xd.c xy.c > > Log Message: > Make local dev_type_*() functions static. While you're doing this kind of cleanup, maybe you could also change static dev_type_open(foo_open); to static dev_open_t foo_open; so we have less unnecessary macro magic for forward declarations. (This is all the dev_type_* macros expand to; there's really no need for them -- and using them is longer than their expansion!)
Re: CVS commit: src/lib/libc/sys
Taylor R Campbell wrote in <20241221185628.a4efaf...@cvs.netbsd.org>: |Module Name: src |Committed By: riastradh |Date: Sat Dec 21 18:56:28 UTC 2024 | |Modified Files: | src/lib/libc/sys: close.2 | |Log Message: |close(2): Document the finality of closing. | |Even if close(2) returns -1 on error, the descriptor is closed (or |was already closed). | |POSIX doesn't specify this, but that's a bug in POSIX (probably to Actually i think there was lots of discussion of this for the 2024 version, and it says For all other error situations (except for [EBADF] where fildes was invalid), fildes shall be closed. It only remains EINTR / POSIX_CLOSE_RESTART as a problem. That is being defined as POSIX_CLOSE_RESTART Allows restarts if a signal interrupts a close operation. This constant shall not be 0 unless posix_close( ) never returns −1 with errno set to [EINTR]. |accommodate some buggy ancient proprietary Unix). Every free |software OS kernel I checked works the same way and it is important |to be able to reliably close descriptors with finality. I have not seen the diff, so it may the complete picture is a different one. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear
Re: CVS commit: src
Taylor R Campbell writes: >> Date: Fri, 20 Dec 2024 10:43:06 -0500 >> From: Greg Troxel >> >> I still am not clear on if having built packages like this as part of >> build.sh, if using the system with normal native X and doing pkgsrc >> builds later is going to be problematic. If that's true, maybe asking >> for packages and passing -x should just be an error. > > I have made `build.sh -x pkg=...' an error for now to avoid confusion. Thanks. I lean to avoiding confusion being more important, and it's all changeable. > oBut just for the record: pkgsrc X11_TYPE=modular has coexisted > peacefully with base MKX11=yes for as long as I can remember. The > pkgsrc packages simply don't link against anything in /usr/X11R7. > I've been doing this on my main laptop for probably a decade, maybe > longer. (Feel free to remove the error if you think this fact > obviates the motivation for it.) It's a fair point that configuring pkgsrc with X11_TYPE=modular and using sets with X is ok, but I don't think pkgsrc being mixed works, and this build doesn't lead to future pkgsrc being configured for modular. I think what you're doing is great progress, and with a sharp edge removed, I cheer you on!
Re: CVS commit: src
> Date: Fri, 20 Dec 2024 10:43:06 -0500 > From: Greg Troxel > > I still am not clear on if having built packages like this as part of > build.sh, if using the system with normal native X and doing pkgsrc > builds later is going to be problematic. If that's true, maybe asking > for packages and passing -x should just be an error. I have made `build.sh -x pkg=...' an error for now to avoid confusion. oBut just for the record: pkgsrc X11_TYPE=modular has coexisted peacefully with base MKX11=yes for as long as I can remember. The pkgsrc packages simply don't link against anything in /usr/X11R7. I've been doing this on my main laptop for probably a decade, maybe longer. (Feel free to remove the error if you think this fact obviates the motivation for it.)
Re: CVS commit: src
In that case it probably deserves a warning if build.sh is given -x, and the comment expanded a bit. It makes sense now that you've explained, but not something I'd expect random build.sh users to understand. I still am not clear on if having built packages like this as part of build.sh, if using the system with normal native X and doing pkgsrc builds later is going to be problematic. If that's true, maybe asking for packages and passing -x should just be an error.
Re: CVS commit: src
> Date: Fri, 20 Dec 2024 09:46:10 -0500 > From: Greg Troxel > > "Taylor R Campbell" writes: > > > build.sh: Use X11_TYPE=modular for build.sh pkg=... by default. > > > > You can override it in your MAKECONF if you want to debug issues in > > pkgsrc with cross-building X11_TYPE=native, but let's try to make > > things work out of the box here if you don't go out of your way. > > I can sort of see where you are coming from, but this seems contrary to > doctrine, which as I understand it, is that the standard approach is to > use -x in build.sh if one wants X. > > Are you having problems with a build.sh without -x, when requesting > packages that need X? Or some other problem? The problem is that none of the pkgsrc build infrastructure for X11_TYPE=native works for cross-builds, so before my change, if you tried to build any packages using X, it would simply barf up a spew of confusing build errors and/or unusably broken packages. (I had only tested the new build.sh command with non-graphical packages before.) I could invest a lot of effort into making X11_TYPE=native work in cross-builds -- I started a few patches which are waiting on the branch since they touch mk/ infrastructure, but there's a lot more to do for nontrivial things like splitting up X11BASE for the host and target systems. And that work is probably not worth doing anyway because the primary reason xsrc and X11_TYPE=native continue exist at all is to support cross-building X for ancient/tiny platforms too weak to do pkgsrc builds. In contrast, pkgsrc cross-builds of X packages do already generally work with X11_TYPE=modular -- that's what I put all my effort into in the past. Bear in mind that `build.sh pkg=...' is still an early-stage draft experiment. Absolutely nothing that matters relies on it, and I might rip it out and do something else instead (like maybe teach it to do pbulk with a limited_list instead or something, for better scripting). Feel free to try it out and tweak it as you need to make it work! If you want to make X11_TYPE=native cross-builds work and teach it to set X11_TYPE=native/modular depending on -x/MKX11=yes or not, go for it; it won't break anything important.
Re: CVS commit: src/sys/kern
thanks, I will take a look! christos > On Dec 16, 2024, at 5:26 AM, J. Hannken-Illjes wrote: > > >> >> On 15. Dec 2024, at 18:42, Christos Zoulas wrote: >> >> Module Name: src >> Committed By: christos >> Date: Sun Dec 15 17:42:34 UTC 2024 >> >> Modified Files: >> src/sys/kern: sys_ptrace_common.c >> >> Log Message: >> PR/58896: Martin Husemann: PT_KILL will not deliver a kill signal to a >> stopped >> process: When the process is stopped, the code resumes it instead of sending >> the signal. Change it so that if we are sending SIGKILL, resume and send >> the signal. >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.93 -r1.94 src/sys/kern/sys_ptrace_common.c > > Christos, > > ATF tests now crash the machine with: > > lib/libc/sys/t_ptrace_wait (358/985): 403 test cases >traceme_lwpinfo0: > [ 1457.3812852] panic: kernel diagnostic assertion "req == PT_KILL || req == > PT_STOP || req == PT_ATTACH" failed: file "sys/kern/sys_ptrace_common.c", > line 973 > > -- > J. Hannken-Illjes - hann...@mailbox.org >
Re: CVS commit: src/sys/kern
> On 15. Dec 2024, at 18:42, Christos Zoulas wrote: > > Module Name: src > Committed By: christos > Date: Sun Dec 15 17:42:34 UTC 2024 > > Modified Files: > src/sys/kern: sys_ptrace_common.c > > Log Message: > PR/58896: Martin Husemann: PT_KILL will not deliver a kill signal to a stopped > process: When the process is stopped, the code resumes it instead of sending > the signal. Change it so that if we are sending SIGKILL, resume and send > the signal. > > > To generate a diff of this commit: > cvs rdiff -u -r1.93 -r1.94 src/sys/kern/sys_ptrace_common.c Christos, ATF tests now crash the machine with: lib/libc/sys/t_ptrace_wait (358/985): 403 test cases traceme_lwpinfo0: [ 1457.3812852] panic: kernel diagnostic assertion "req == PT_KILL || req == PT_STOP || req == PT_ATTACH" failed: file "sys/kern/sys_ptrace_common.c", line 973 -- J. Hannken-Illjes - hann...@mailbox.org signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/sys/dev/scsipi
On Sat, Nov 23, 2024 at 08:32:43PM -0800, T K Spindler (moof) wrote: > On Sat, Nov 23, 2024 at 09:59:14PM +0100, Michael van Elst wrote: > > On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote: > > > > > Alas, even with this change, on NetBSD 10 (haven't yet tried booting > > > with -current), it's still insufficient for the disks on the same > > > target from attaching except for the first one; they do still show > > > up in `scsictl sd0 reportluns all`, though - four on one target, > > > eight on the other. > > > > Seems to work here. > > It *does* work in -current for me as well, so I'll take that as a win. > > [ 2.027910] sd11 at scsibus0 target 2 lun 3: R001> disk fixed On netbsd-10 with the scsiconf.c change: [25.423073] scsibus0 at iscsi0: 1 target, 16 luns per target [25.433074] sd0 at scsibus0 target 0 lun 0: disk fixed [25.433074] sd0: fabricating a geometry [25.433074] sd0: 32768 MB, 32768 cyl, 64 head, 32 sec, 512 bytes/sect x 67108864 sectors [25.433074] sd0: fabricating a geometry [26.053107] sd1 at scsibus0 target 0 lun 1: disk fixed [26.053107] sd1: fabricating a geometry [26.053107] sd1: 10240 MB, 10240 cyl, 64 head, 32 sec, 512 bytes/sect x 20971520 sectors [26.063108] sd1: fabricating a geometry [26.063108] sd2 at scsibus0 target 0 lun 2: disk fixed [26.063108] sd2: fabricating a geometry [26.063108] sd2: 10240 MB, 10240 cyl, 64 head, 32 sec, 512 bytes/sect x 20971520 sectors [26.073108] sd2: fabricating a geometry [26.073108] sd3 at scsibus0 target 0 lun 3: disk fixed [26.073108] sd3: fabricating a geometry [26.073108] sd3: 8192 MB, 8192 cyl, 64 head, 32 sec, 512 bytes/sect x 16777216 sectors [26.083110] sd3: fabricating a geometry [26.083110] sd4 at scsibus0 target 0 lun 4: disk fixed [26.083110] sd4: fabricating a geometry [26.083110] sd4: 8192 MB, 8192 cyl, 64 head, 32 sec, 512 bytes/sect x 16777216 sectors [26.093110] sd4: fabricating a geometry [26.093110] sd5 at scsibus0 target 0 lun 5: disk fixed [26.093110] sd5: fabricating a geometry [26.093110] sd5: 8192 MB, 8192 cyl, 64 head, 32 sec, 512 bytes/sect x 16777216 sectors [26.103110] sd5: fabricating a geometry [26.103110] sd6 at scsibus0 target 0 lun 6: disk fixed [26.103110] sd6: fabricating a geometry [26.103110] sd6: 8192 MB, 8192 cyl, 64 head, 32 sec, 512 bytes/sect x 16777216 sectors [26.113111] sd6: fabricating a geometry [26.113111] sd0: async, 8-bit transfers, tagged queueing [26.113111] sd1: async, 8-bit transfers, tagged queueing [26.113111] sd2: async, 8-bit transfers, tagged queueing [26.113111] sd3: async, 8-bit transfers, tagged queueing [26.113111] sd4: async, 8-bit transfers, tagged queueing [26.113111] sd5: async, 8-bit transfers, tagged queueing [26.113111] sd6: async, 8-bit transfers, tagged queueing Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: CVS commit: src/sys/dev/scsipi
On Sat, Nov 23, 2024 at 09:59:14PM +0100, Michael van Elst wrote: > On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote: > > > Alas, even with this change, on NetBSD 10 (haven't yet tried booting > > with -current), it's still insufficient for the disks on the same > > target from attaching except for the first one; they do still show > > up in `scsictl sd0 reportluns all`, though - four on one target, > > eight on the other. > > Seems to work here. It *does* work in -current for me as well, so I'll take that as a win. [ 2.027910] sd11 at scsibus0 target 2 lun 3: disk fixed
Re: CVS commit: src/sys/dev/scsipi
On Fri, Nov 22, 2024 at 12:44:57PM -0800, T K Spindler (moof) wrote:
> Alas, even with this change, on NetBSD 10 (haven't yet tried booting
> with -current), it's still insufficient for the disks on the same
> target from attaching except for the first one; they do still show
> up in `scsictl sd0 reportluns all`, though - four on one target,
> eight on the other.
Seems to work here.
tazz: {2} sudo scsictl sd6 reportluns
Password:
/dev/rsd6: lun 0
/dev/rsd6: lun 1
/dev/rsd6: lun 2
/dev/rsd6: lun 3
/dev/rsd6: lun 4
/dev/rsd6: lun 5
/dev/rsd6: lun 6
tazz: {4} sudo scsictl sd12 reportluns
/dev/rsd12: lun 0
/dev/rsd12: lun 1
/dev/rsd12: lun 2
/dev/rsd12: lun 3
/dev/rsd12: lun 4
/dev/rsd12: lun 5
/dev/rsd12: lun 6
scsibus4 at iscsi0: 1 target, 16 luns per target
sd6 at scsibus4 target 0 lun 0: disk fixed
sd6: fabricating a geometry
sd6: 32768 MB, 32768 cyl, 64 head, 32 sec, 512 bytes/sect x 67108864 sectors
sd6: fabricating a geometry
sd6: 4194304 trailing sectors not covered by disklabel
dk13 at sd6: "dummy/a", 614400 blocks at 512, type: ffs
dk14 at sd6: "dummy/b", 4198400 blocks at 614912, type: swap
dk15 at sd6: "dummy/e", 4352 blocks at 4813312, type: ffs
dk16 at sd6: "dummy/f", 2048000 blocks at 4812, type: ffs
dk17 at sd6: "dummy/g", 12533248 blocks at 50381312, type: ffs
sd7 at scsibus4 target 0 lun 1: disk fixed
sd7: fabricating a geometry
sd7: 10240 MB, 10240 cyl, 64 head, 32 sec, 512 bytes/sect x 20971520 sectors
sd7: fabricating a geometry
dk18 at sd7: "Hardfile/a", 320 blocks at 512, type: ffs
dk19 at sd7: "Hardfile/b", 16384000 blocks at 3200512, type: swap
dk20 at sd7: "Hardfile/e", 1387008 blocks at 19584512, type: ffs
sd8 at scsibus4 target 0 lun 2: disk fixed
sd8: fabricating a geometry
sd8: 10240 MB, 10240 cyl, 64 head, 32 sec, 512 bytes/sect x 20971520 sectors
sd8: fabricating a geometry
dk21 at sd8: "work/d", 20971008 blocks at 512, type: ffs
sd9 at scsibus4 target 0 lun 3: disk fixed
sd9: fabricating a geometry
sd9: 8192 MB, 8192 cyl, 64 head, 32 sec, 512 bytes/sect x 16777216 sectors
sd9: fabricating a geometry
sd10 at scsibus4 target 0 lun 4: disk fixed
sd10: fabricating a geometry
sd10: 8192 MB, 8192 cyl, 64 head, 32 sec, 512 bytes/sect x 16777216 sectors
sd10: fabricating a geometry
sd6: 4194304 trailing sectors not covered by disklabel
sd11 at scsibus4 target 0 lun 5: disk fixed
sd6: 4194304 trailing sectors not covered by disklabel
sd11: fabricating a geometry
sd11: 8192 MB, 8192 cyl, 64 head, 32 sec, 512 bytes/sect x 16777216 sectors
sd11: fabricating a geometry
sd12 at scsibus4 target 0 lun 6: disk fixed
sd12: fabricating a geometry
sd12: 8192 MB, 8192 cyl, 64 head, 32 sec, 512 bytes/sect x 16777216 sectors
sd12: fabricating a geometry
sd6: async, 8-bit transfers, tagged queueing
sd7: async, 8-bit transfers, tagged queueing
sd8: async, 8-bit transfers, tagged queueing
sd9: async, 8-bit transfers, tagged queueing
sd10: async, 8-bit transfers, tagged queueing
sd11: async, 8-bit transfers, tagged queueing
sd12: async, 8-bit transfers, tagged queueing
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: CVS commit: src/sys/dev/scsipi
> Modified Files: > src/sys/dev/scsipi: scsiconf.c > > Log Message: > The code tried to limit number of LUNs per target to 3, but would > only default to a single LUN when that limit is exceeded. > > With the limit removed, more LUNs will be attached (up to the limit > imposed by the host adapter driver). > > To generate a diff of this commit: > cvs rdiff -u -r1.305 -r1.306 src/sys/dev/scsipi/scsiconf.c Alas, even with this change, on NetBSD 10 (haven't yet tried booting with -current), it's still insufficient for the disks on the same target from attaching except for the first one; they do still show up in `scsictl sd0 reportluns all`, though - four on one target, eight on the other.
Re: CVS commit: src/usr.bin/make
In article , Roland Illig wrote: >Am 18.11.2024 um 17:29 schrieb Christos Zoulas: >> In article <20241110023915.09cd6f...@cvs.netbsd.org>, >> Simon J. Gerraty wrote: >>> -=-=-=-=-=- >>> >>> Module Name:src >>> Committed By: sjg >>> Date: Sun Nov 10 02:39:14 UTC 2024 >>> >>> Modified Files: >>> src/usr.bin/make: main.c make.1 >>> >>> Log Message: >>> make: allow -f .../Makefile >>> >>> If the arg to -f or an entry in .MAKE.MAKEFILE_PREFERENCE >>> starts with ".../" look for the rest of the path in .CURDIR >>> and above. >>> >>> Reviewed by: rillig >> >> I don't like these magical conventions that do not match filesystem >> behavior. For example what happens if there actually is a "..." directory? >> I can certainly make one... Why don't use a keyword instead to indicate >> the operation? > >It's analogous to the existing '-m .../mk/sys.mk' option, therefore I >don't see a big drawback. > >As you noted, a directory named '...' would interfere with this pattern. >If the option had been '-f scan:custom.mk' instead, a file named >'scan:custom.mk' would interfere in the same way. So I guess whatever >the pattern, it will not be completely conflict-free. Yes, but it could be something like search(.., custom.mk) christos
Re: CVS commit: src/usr.bin/make
Am 18.11.2024 um 17:29 schrieb Christos Zoulas: > In article <20241110023915.09cd6f...@cvs.netbsd.org>, > Simon J. Gerraty wrote: >> -=-=-=-=-=- >> >> Module Name: src >> Committed By:sjg >> Date:Sun Nov 10 02:39:14 UTC 2024 >> >> Modified Files: >> src/usr.bin/make: main.c make.1 >> >> Log Message: >> make: allow -f .../Makefile >> >> If the arg to -f or an entry in .MAKE.MAKEFILE_PREFERENCE >> starts with ".../" look for the rest of the path in .CURDIR >> and above. >> >> Reviewed by: rillig > > I don't like these magical conventions that do not match filesystem > behavior. For example what happens if there actually is a "..." directory? > I can certainly make one... Why don't use a keyword instead to indicate > the operation? It's analogous to the existing '-m .../mk/sys.mk' option, therefore I don't see a big drawback. As you noted, a directory named '...' would interfere with this pattern. If the option had been '-f scan:custom.mk' instead, a file named 'scan:custom.mk' would interfere in the same way. So I guess whatever the pattern, it will not be completely conflict-free. Roland
Re: CVS commit: src/usr.bin/make
In article <20241110023915.09cd6f...@cvs.netbsd.org>, Simon J. Gerraty wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: sjg >Date: Sun Nov 10 02:39:14 UTC 2024 > >Modified Files: > src/usr.bin/make: main.c make.1 > >Log Message: >make: allow -f .../Makefile > >If the arg to -f or an entry in .MAKE.MAKEFILE_PREFERENCE >starts with ".../" look for the rest of the path in .CURDIR >and above. > >Reviewed by: rillig I don't like these magical conventions that do not match filesystem behavior. For example what happens if there actually is a "..." directory? I can certainly make one... Why don't use a keyword instead to indicate the operation? christos
Re: CVS commit: src/sys/dev/pci
On 2024/11/11 23:23, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Mon Nov 11 14:23:11 UTC 2024 > > Modified Files: > src/sys/dev/pci: pcidevs > > Log Message: > Add many Brainboxes devices. Repoted in PR/kern 55824 by Cameron Williams. s/55824/58824/ > > To generate a diff of this commit: > cvs rdiff -u -r1.1512 -r1.1513 src/sys/dev/pci/pcidevs > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/kern
Date:Sun, 10 Nov 2024 09:35:29 +
From:Taylor R Campbell
Message-ID: <20241110093534.e816384...@mail.netbsd.org>
| Yikes! Do you have a reproducer handy for this?
Yes, it turns out to be trivially easy to do, once the
bug is understood - just very rare to actually happen in
anything in the wild.
All you need is
main() {
dup3(0, 5, O_CLOEXEC);
/* use fcntl(5, F_GETFD) and verify
close-on-exec is set if you want */
execl("verifier", "verifier", NULL);
}
plus all the boilerplate (#include) etc, and a little error checking, etc)
to
where "verifier" is just
#!/bin/sh
fdflags -v
(executable) - or anything else which checks there are no open
fds in the new process which shouldn't be there and none with
close-on-exec set which should be impossible in a newly created
process.
Then you need another main() using fcntl(F_DUPFD_CLOEXEC) (or
also put that in the same one) and another which does whatever
is required to get the kernel fd_clone() function to be called
with flags containing O_CLOEXEC, that one I can't do (now anyway)
because I didn't bother to work out what that would be exactly.
| Can you file a PR to record the reproducer, and track pullups?
I could, but I don't really think it is needed for this one.
No ATF tests to check it either - the tests can only ever be
for the specific errors (specific ways of turning on close-on-exec
that are done improperly) which would now have to be some new
way (some new added functionality done improperly again) which
we cannot possibly write a test for now, only for the cases that
are already fixed (or were never wrong) which no-one is ever
going to deliberately (or even accidentally) go and break now.
I will submit pullups for it, and make sure they happen, so there
also isn't really a need for tracking anything, beyond what the
releng pullup tickets provide. There doesn't even need to be
much testing in HEAD for this one before the pullups happen, the
fixes are so obvious, and so obviously correct.
A bigger issue would be if there's another case hiding somewhere
that I didn't find - I can't test for that as I don't know what
it is, if it exists. However I doubt there is such a thing.
This is rarely observed in anything real, as all it takes is
one instance of setting close-on-exec the right way, even if that
fd is no longer still open when the exec happens, to hide the
existence of the bug in any other fd's which enabled the flag
using a method which the kernel didn't do properly. So if you
added
fcntl(dup(0), F_SETFD, 1);
to the above program then the broken case dup3() above, would
never be noticed.
Right now I need to work out how my changes to the shell (that
I was testing when I encountered the kernel problem - I was looking
very closely at when close-on-exec happened, and didn't) seem to
have broken the b5 i386 testbed (and perhaps more) quite so badly.
kre
Re: CVS commit: src/sys/kern
> Module Name:src > Committed By: kre > Date: Sun Nov 10 00:11:43 UTC 2024 > > Modified Files: > src/sys/kern: kern_descrip.c > > Log Message: > Make O_CLOEXEC always close specified files on exec > > It turns out that close-on-exec doesn't always close on exec. Yikes! Do you have a reproducer handy for this? Can you file a PR to record the reproducer, and track pullups?
Re: CVS commit: src/share/man/man4
Date:Sat, 9 Nov 2024 03:24:00 + (UTC) From:Charlotte Koch Message-ID: <5f8461f1-d8bc-c031-dcd7-b710c613c...@netbsd.org> | Sure thing, I went ahead and made it clearer. The wedge names do in fact | start with 0. Thanks - that is now much clearer. kre ps: if only I had ever even seen an Atari... (somehow, never happened).
Re: CVS commit: src/share/man/man4
On Fri, 8 Nov 2024, Robert Elz wrote: You also might like to indicate whether "first" means "number" is 0 or 1. Sure thing, I went ahead and made it clearer. The wedge names do in fact start with 0. Charlotte
Re: CVS commit: src/share/man/man4
Date:Fri, 8 Nov 2024 07:44:46 + From:"Charlotte Koch" Message-ID: <20241108074446.954adf...@cvs.netbsd.org> | dk.4: Clarify that DKWEDGE_METHOD_TOS actually pertains to the AHDI spec You also might like to indicate whether "first" means "number" is 0 or 1. kre
Can we remove SYSCTL_DESCR()? (Re: CVS commit: src/sys/external/bsd/vchiq/dist/interface/vchiq_arm)
On 2024/11/07 18:51, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Thu Nov 7 09:51:00 UTC 2024 Modified Files: src/sys/external/bsd/vchiq/dist/interface/vchiq_arm: vchiq_kmod_netbsd.c Log Message: vchiq: Use SYSCTL_DESCR() to comply with SYSCTL_INCLUDE_DESCR option Probably, it would be better to remove SYSCTL_DESCR() macro, and check SYSCTL_INCLUDE_DESCR only once in sysctl_createv(9). Objections? Thanks, rin
Re: CVS commit: src/bin/ls
Robert Elz wrote: > | How about the attached diff? > > Yes, that all looks good. Ok, just committed that together with your other suggestions. Thanks for the feedback! -Jan
re: CVS commit: src/distrib/sets/lists/xdebug
"Rin Okuyama" writes: > Module Name: src > Committed By: rin > Date: Wed Nov 6 04:44:12 UTC 2024 > > Modified Files: > src/distrib/sets/lists/xdebug: md.sparc > > Log Message: > xdebug: md.sparc: Fix confusion for pnozz_drv.so.0.debug > > which was registered both as valid and obsolete files at the same time. thanks.
Re: CVS commit: src/bin/ls
Date:Tue, 5 Nov 2024 16:50:06 -0500 From:Jan Schaumann Message-ID: | +In multi-column output | +.Pq Fl C No or Fl x , | +a total sum for all the file sizes is output on a line before the listing. should probably say (the first two lines there, and then): a total sum of all file sizes in each directory listed is output... That is ls -s file1 file2 prints no total line (that's also the case where ls -l doesn't print a total line). and certainly never should for just ls -s file (or -l) But ls -s dir1 dir2 prints two total lines, one for each of dir1 and dir2 kre
Re: CVS commit: src/bin/ls
Date:Tue, 5 Nov 2024 16:50:06 -0500 From:Jan Schaumann Message-ID: That is, it looks good aside from this: | +.Ns ( Fl C | +or | +.Fl x Ns ), Ns as the first macro on a line makes no sense, there is nothing to have no space after, try instead .Pq Fl C No or Fl x , kre
Re: CVS commit: src/bin/ls
Date:Tue, 5 Nov 2024 16:50:06 -0500 From:Jan Schaumann Message-ID: | How about the attached diff? Yes, that all looks good. I wasn't sure the change to printcol() would be that simple, but it looks good, the one to printacol() is exactly as I imagined it! kre
Re: CVS commit: src/bin/ls
Robert Elz wrote:
> Is is the output format which is chosen (by option, or by
> using the rule to select the default) which affects what is
> output.
>
> And I believe that the -x and -C variation depending upon how
> many columns are output really is a bug, that should just be
> fixed.
How about the attached diff?
That fixes '-xs' and '-Cs' to print 'total' even if a
single-column is all that can be printed. With that:
ls -s-> prints 'total'
ls -s1 -> does not print 'total'
ls -s | cat -> does not print 'total'
ls -Cs | cat -> prints 'total'
ls -ms -> does not print 'total'
ls -xs -> prints 'total'
ls -xs | cat -> prints 'total'
COLUMNS=1 ls -s -> prints 'total'
COLUMNS=1 ls -xs -> prints 'total'
-Jan
Index: ls.1
===
RCS file: /cvsroot/src/bin/ls/ls.1,v
retrieving revision 1.81
diff -b -u -r1.81 ls.1
--- ls.116 May 2020 18:31:45 - 1.81
+++ ls.15 Nov 2024 21:41:30 -
@@ -225,8 +225,11 @@
.Sx ENVIRONMENT )
where partial units are rounded up to the
next integer value.
-If the output is to a terminal, a total sum for all the file
-sizes is output on a line before the listing.
+In multi-column output
+.Ns ( Fl C
+or
+.Fl x Ns ),
+a total sum for all the file sizes is output on a line before the listing.
.It Fl T
When used with the
.Fl l
Index: print.c
===
RCS file: /cvsroot/src/bin/ls/print.c,v
retrieving revision 1.57
diff -b -u -r1.57 print.c
--- print.c 17 May 2020 23:34:11 - 1.57
+++ print.c 5 Nov 2024 21:41:30 -
@@ -231,6 +231,8 @@
colwidth += 1;
+ printtotal(dp); /* "total: %u\n" */
+
if (termwidth < 2 * colwidth) {
printscol(dp);
return;
@@ -262,8 +264,6 @@
if (num % numcols)
++numrows;
- printtotal(dp); /* "total: %u\n" */
-
for (row = 0; row < numrows; ++row) {
for (base = row, chcnt = col = 0; col < numcols; ++col) {
chcnt = printaname(array[base], dp->s_inode,
@@ -298,6 +298,8 @@
colwidth += 1;
+ printtotal(dp); /* "total: %u\n" */
+
if (termwidth < 2 * colwidth) {
printscol(dp);
return;
@@ -306,8 +308,6 @@
numcols = termwidth / colwidth;
colwidth = termwidth / numcols; /* spread out if possible */
- printtotal(dp); /* "total: %u\n" */
-
chcnt = col = 0;
for (p = dp->list; p; p = p->fts_link) {
if (IS_NOPRINT(p))
Re: CVS commit: src/bin/ls
Date:Tue, 5 Nov 2024 13:32:01 -0500 From:Jan Schaumann Message-ID: | "If the output is to a terminal and results in multiple | columns being printed, a total sum for all the file | sizes is output on a line before the listing." It actually has almost nothing to do with whether or not the output is to a terminal (that part of the description that was there is at best misleading). The "almost" is that -C is the default format if the output is a terminal, and -1 if it isn't. That's as far as "terminal" is relevant, but that can alter the results. Is is the output format which is chosen (by option, or by using the rule to select the default) which affects what is output. And I believe that the -x and -C variation depending upon how many columns are output really is a bug, that should just be fixed. kre
Re: CVS commit: src/bin/ls
Robert Elz wrote: > It is more complex than that Hmm. Maybe "If the output is to a terminal and results in multiple columns being printed, a total sum for all the file sizes is output on a line before the listing." ? (The fact that "total" is printed for '-l' whether or not output goes to a terminal is covered under the '-l' description and combining with '₋s' does not change that behavior.) -Jan
Re: CVS commit: src/bin/ls
Date:Tue, 5 Nov 2024 04:04:19 + From:"Jan Schaumann" Message-ID: <20241105040419.6c798f...@cvs.netbsd.org> | Note that when '-s' is combined with '-1', the 'total' is _not_ printed. It is more complex than that (though that is correct, and applies when the -1 is explicit, or when it is used because output is not to a tty). ls has 5 output formats, -C -1 -l -m and -x The "total:" header line is only printed in -C (the default for output to a terminal, and only with -s), -x (also only with -s), and -l (traditional long format, when it is almost always printed). The other 2 formats -1 (the default when output is not a terminal) and -m never print the total header, with or without -s. -C and -x are weird, (-x is just -C transposed), and if they actually print multiple columns, they will also print the totals header. If only 1 column is possible (if the line width isn't wide enough for more) then they transform into -1, and don't print the totals (which they only ever print with -s). That could perhaps be considered a bug - which would be trivial to fix. Absurdly trivial for -x (just move a couple of lines), not much harder for -C (insert a couple of lines). kre
Re: CVS commit: src
> Module Name:src > Committed By: christos > Date: Sun Nov 3 22:24:23 UTC 2024 > > Modified Files: > src/distrib/sets/lists/comp: ad.arm ad.m68k ad.mips ad.powerpc > ad.riscv > ad.sh3 md.alpha md.amd64 md.hppa md.i386 md.ia64 md.or1k md.sparc > md.vax > src/include: lwp.h > ... > Log Message: > Split __lwp_getprivate_fast and __lwp_*tcb from mcontext.h into a separate > lwp.h file. Please revert this immediately. We discussed this extensively in private the other day. Everything about this commit is exactly the opposite of the agreement we came to about how this should be done, as documented in PR misc/58796 (https://gnats.NetBSD.org/58796), which you didn't cite for cross-reference as I requested but which I quote here: > 1. Move the definitions of _lwp_getprivate/gettcb/settcb_fast (plus > TLS_TP_OFFSET and TLS_DTV_OFFSET, and whatever other parts are > directly relevant) to a new header file . > > 2. Use #include in the Arm and PowerPC > implementations (and whichever other ones > need _lwp_getprivate/setprivate or similar). > > 3. Include explicitly in all users of > _lwp_getprivate/gettcb/settcb_fast instead of using the kooky > _RTLD_SOURCE/_LIBC_SOURCE/__LIBPTHREAD_SOURCE__ conditionalization. Instead of (1), you have created a new dumping ground machine/lwp.h which will invite definitions unrelated to the lwp private/tcb pointer; this is exactly what I objected to. (I suggested an alternative machine/lwp_tls.h if the `_private.h' suffix is unsettling, just as long as it is not `machine/lwp.h', or if you really insist on machine/lwp.h, then at least put #ifdef _KERNEL #error with a message clearly stating its narrow scope.) Instead of (2) where each header file includes what it needs first, you have created a bogus ordering dependency for so it cannot be independently included. Instead of (3), you have polluted with private definitions that were formerly exposed only to rtld/libpthread/libc internals. And on top of this, you broke almost all the builds (52 out of 73): https://releng.netbsd.org/builds/HEAD/202411040510Z/ You should expect changes which are exactly the opposite of how the extensive discussion concluded to be presumptively controversial and inappropriate for committing without public review. So please revert in the next 12h or I will.
re: CVS commit: src/share/mk
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Fri Nov 1 23:06:17 UTC 2024 > > Modified Files: > src/share/mk: bsd.lib.mk > > Log Message: > We need -fPIC too otherwise we end up with R_X86_64_PLT32 and not > R_X86_64_REX_GOTPCRELX and we can't build .so objects. I think we can > remove the -fPIE and use only -fPIC but this works for now. -fPIE, -fPIC, -fpie, -fpic, and nothing, and effectively a 5-state thing. either *none*, one of large or small, and one of pie or pic. the last option seen is what matters. ie, it is not useful (but not harmful) to leave -fPIE if -fPIC is the last option. (the gcc manual isn't 100% clear about this being a state, and posts in bug reports often call it a 3-state thing, forgetting about the upper and lower case variants, that change the defined value of __PIC__ and __PIE__ from 1 to 2.) .mrg.
Re: CVS commit: src
In article <20241031192407.ab67060...@jupiter.mumble.net>, Taylor R Campbell wrote: >> Module Name:src >> Committed By: christos >> Date: Wed Oct 30 18:09:19 UTC 2024 >> >> Modified Files: >> src/distrib/sets/lists/base: mi shl.mi >> src/distrib/sets/lists/comp: mi shl.mi >> src/distrib/sets/lists/debug: mi shl.mi >> [...] >> Log Message: >> Hook zstd to the build and enable it for libarchive and file. > >Publishing libzstd.so looks risky because there are probably many >applications out there in pkgsrc which it may affect. > >I don't think we should do this without a public discussion, review of >what the maintenance burden and consequences are for pkgsrc, and >coordination with pkgsrc builtin.mk. > >At the very least, I think we should start with a private static >library, since we don't currently have a mechanism for private shared >libraries (as suggested in PR lib/58648: private shared libraries >should go in /usr/lib/private, not /usr/lib) -- and do this promptly >before anything starts relying on finding libzstd.so.0 in /usr/lib. Converting to a private static library is almost done. christos
Re: CVS commit: src
[resent from intended address, oops] > Module Name:src > Committed By: christos > Date: Wed Oct 30 18:09:19 UTC 2024 > > Modified Files: > src/distrib/sets/lists/base: mi shl.mi > src/distrib/sets/lists/comp: mi shl.mi > src/distrib/sets/lists/debug: mi shl.mi > [...] > Log Message: > Hook zstd to the build and enable it for libarchive and file. Publishing libzstd.so looks risky because there are probably many applications out there in pkgsrc which it may affect. I don't think we should do this without a public discussion, review of what the maintenance burden and consequences are for pkgsrc, and coordination with pkgsrc builtin.mk. At the very least, I think we should start with a private static library, since we don't currently have a mechanism for private shared libraries (as suggested in PR lib/58648: private shared libraries should go in /usr/lib/private, not /usr/lib) -- and do this promptly before anything starts relying on finding libzstd.so.0 in /usr/lib.
Re: CVS commit: src
> Module Name:src > Committed By: christos > Date: Wed Oct 30 18:09:19 UTC 2024 > > Modified Files: > src/distrib/sets/lists/base: mi shl.mi > src/distrib/sets/lists/comp: mi shl.mi > src/distrib/sets/lists/debug: mi shl.mi > [...] > Log Message: > Hook zstd to the build and enable it for libarchive and file. Publishing libzstd.so looks risky because there are probably many applications out there in pkgsrc which it may affect. I don't think we should do this without a public discussion, review of what the maintenance burden and consequences are for pkgsrc, and coordination with pkgsrc builtin.mk. At the very least, I think we should start with a private static library, since we don't currently have a mechanism for private shared libraries (as suggested in PR lib/58648: private shared libraries should go in /usr/lib/private, not /usr/lib) -- and do this promptly before anything starts relying on finding libzstd.so.0 in /usr/lib.
Re: CVS commit: src/lib/libm
On Wed, 30 Oct 2024 06:59:45 Taylor R Campbell wrote: > > Date: Wed, 30 Oct 2024 04:30:44 +0900 > > From: Izumi Tsutsui > > > > riastradh@ wrote: > > > Is this configuration > > > relevant for real-world hardware or is it more of a `for fun' option? > > > > The only use case is to run NetBSD/mac68k on XC68LC040 machines. > > > > It looks he "options FPU_EMULATE" for m68k doesn't handle > > XC68LC040 errata properly so most FP programs randomly dumps core > > on it (though FPU_EMULATE works on rare MC68LC040). > > n> In the real world only several Machintosh machines (LC630 etc.) > > > were shipped with XC68LC040 and users of such machines want > > softfloat, but most such geek users just replaced LC040 with 68040. > > > > I have LC630 with MC68LC040 and HP9000/382 with (replaced) XC68LC040 > > to debug FPU_EMULATE on LC040, but it has been in my deep todo list.. > > Cool, thanks for the background! > > > > Maybe we should have an m68k MKSOFTFLOAT=yes autobuild? > > > > We can do it, but IIRC there were several discussions if we provide > > softfloat m68k binaries maybe we should define a differnt MACHINE_ARCH. > > Yes, I think we need a new MACHINE_ARCH for that, maybe m68ksf. But > maybe effort is better spent on making FPU_EMULATE work than on > dealing with a new ABI. My new computer a PowerBook 520 may have an affected cpu. The initial instability I am looking into and have a temporary fix for: https://mail-index.netbsd.org/tech-kern/2024/10/26/msg029805.html So far it's stable no crashing on "ls -lh" anymore and I can play audio. I believe that apple had a service programme back in the day that replaced affected cpus for those that requested it (but im not sure). Is there a test that I can run that would determine if my cpu is affected? Best regards, Nat
Re: CVS commit: src/lib/libm
On Tue, Oct 29, 2024 at 07:59:45PM +, Taylor R Campbell wrote: > Yes, I think we need a new MACHINE_ARCH for that, maybe m68ksf. But > maybe effort is better spent on making FPU_EMULATE work than on > dealing with a new ABI. I think this is impossible w/o compiler/linker support and doing special userland builds for the affected CPUs. And when you need a special userland, the softloat thing is the easier way out :-) Basically Apple shipped "a few" systems with a pre-production LC040 chip that has a mask error that kills emulation of the fpu instructions as the chip looses data when it handles the "unimplemented" trap for 0xF... instructions. The errata is hard to find nowadays, PR 13078 has the info. Possible workarounds: - use softfloat userland - replace chip with a fixed LC040 or a full MC040 - use userland compiled so that it has a NOP before any FPU instruction Martin
Re: CVS commit: src/lib/libm
> Date: Wed, 30 Oct 2024 04:30:44 +0900 > From: Izumi Tsutsui > > riastradh@ wrote: > > > Is this configuration > > relevant for real-world hardware or is it more of a `for fun' option? > > The only use case is to run NetBSD/mac68k on XC68LC040 machines. > > It looks he "options FPU_EMULATE" for m68k doesn't handle > XC68LC040 errata properly so most FP programs randomly dumps core > on it (though FPU_EMULATE works on rare MC68LC040). > n> In the real world only several Machintosh machines (LC630 etc.) > were shipped with XC68LC040 and users of such machines want > softfloat, but most such geek users just replaced LC040 with 68040. > > I have LC630 with MC68LC040 and HP9000/382 with (replaced) XC68LC040 > to debug FPU_EMULATE on LC040, but it has been in my deep todo list.. Cool, thanks for the background! > > Maybe we should have an m68k MKSOFTFLOAT=yes autobuild? > > We can do it, but IIRC there were several discussions if we provide > softfloat m68k binaries maybe we should define a differnt MACHINE_ARCH. Yes, I think we need a new MACHINE_ARCH for that, maybe m68ksf. But maybe effort is better spent on making FPU_EMULATE work than on dealing with a new ABI.
Re: CVS commit: src/lib/libm
riastradh@ wrote: > Interesting, thanks, so that means we don't have any automatic builds > (let alone tests) of m68k MKSOFTFLOAT=yes? Currently no m68k architecture that use softfloat by default, so MKSOFTFLOAT is optional. > Is this configuration > relevant for real-world hardware or is it more of a `for fun' option? The only use case is to run NetBSD/mac68k on XC68LC040 machines. It looks he "options FPU_EMULATE" for m68k doesn't handle XC68LC040 errata properly so most FP programs randomly dumps core on it (though FPU_EMULATE works on rare MC68LC040). In the real world only several Machintosh machines (LC630 etc.) were shipped with XC68LC040 and users of such machines want softfloat, but most such geek users just replaced LC040 with 68040. I have LC630 with MC68LC040 and HP9000/382 with (replaced) XC68LC040 to debug FPU_EMULATE on LC040, but it has been in my deep todo list.. > Maybe we should have an m68k MKSOFTFLOAT=yes autobuild? We can do it, but IIRC there were several discussions if we provide softfloat m68k binaries maybe we should define a differnt MACHINE_ARCH. --- Izumi Tsutsui
Re: CVS commit: src/lib/libm
> Date: Wed, 30 Oct 2024 01:45:45 +1100 > From: Nathanial Sloss > > On Tue, 29 Oct 2024 23:30:47 Taylor R Campbell wrote: > > > Pull in missing functions for MKSOFTFLOAT. > > > > That's interesting, how did you notice these were missing? What build > > does this affect? > > mac68k MKSOFTFLOAT. > > > > I'm surprised because I thought the libm build checked the _exact_ set > > of global dynamic symbols defined by libm.so, so if anything was > > missing it should be detected at build-time -- and if anything was > > added without updating a corresponding .expsym file, it should break > > the build. > > That's exactly what happened the expected symbols did not match those in libm > functions were missing. The build broke for m68k soft float without this > change. As you can see I only added this to the m68k section. The expected > file required nexttoward and s_rintl and similar to be apart of libm. Interesting, thanks, so that means we don't have any automatic builds (let alone tests) of m68k MKSOFTFLOAT=yes? Is this configuration relevant for real-world hardware or is it more of a `for fun' option? Maybe we should have an m68k MKSOFTFLOAT=yes autobuild?
Re: CVS commit: src/sys/dev/scsipi
My aplogies. I've removed scsipi_done_once and have commited your alternative change. I must have tried this earlier and made an error (not as you intended). Best regards, Nat
Re: CVS commit: src/lib/libm
On Tue, 29 Oct 2024 23:30:47 Taylor R Campbell wrote: > > Module Name:src > > Committed By: nat > > Date: Tue Oct 29 01:34:18 UTC 2024 > > > > Modified Files: > > src/lib/libm: Makefile > > > > Log Message: > > Pull in missing functions for MKSOFTFLOAT. > > That's interesting, how did you notice these were missing? What build > does this affect? mac68k MKSOFTFLOAT. > > I'm surprised because I thought the libm build checked the _exact_ set > of global dynamic symbols defined by libm.so, so if anything was > missing it should be detected at build-time -- and if anything was > added without updating a corresponding .expsym file, it should break > the build. That's exactly what happened the expected symbols did not match those in libm functions were missing. The build broke for m68k soft float without this change. As you can see I only added this to the m68k section. The expected file required nexttoward and s_rintl and similar to be apart of libm. Best regards, Nat
Re: CVS commit: src/lib/libm
> Module Name:src > Committed By: nat > Date: Tue Oct 29 01:34:18 UTC 2024 > > Modified Files: > src/lib/libm: Makefile > > Log Message: > Pull in missing functions for MKSOFTFLOAT. That's interesting, how did you notice these were missing? What build does this affect? I'm surprised because I thought the libm build checked the _exact_ set of global dynamic symbols defined by libm.so, so if anything was missing it should be detected at build-time -- and if anything was added without updating a corresponding .expsym file, it should break the build.
Re: CVS commit: src/sys/dev/scsipi
> Module Name:src
> Committed By: nat
> Date: Mon Oct 28 14:36:43 UTC 2024
>
> Modified Files:
> src/sys/dev/ic: ncr5380sbc.c
> src/sys/dev/scsipi: scsipi_base.c scsipiconf.h
>
> Log Message:
> Introduce scsipi_done_once.
>
> This allows for transfers to be sucessfully aborted on the ncr5380sbc(4).
>
> This may be usefull in future for other scsi controllers.
I'm confused, didn't we conclude this change has to be unnecessary
months ago?
It is very weird that such a change to the fundamental control flow of
scsi transfers is needed for one particular driver, which makes me
strongly suspect something is wrong with that driver in particular --
or there's something wrong with the scsi subsystem's control flow
itself, which is _really important_ to understand before we flail
around with hacks in the driver-independent scsi subsystem, because
whatever the issue is might affect all drivers.
> /* Tell common SCSI code it is done. */
> - scsipi_done(xs);
> + scsipi_done_once(xs);
>
> sc->sc_state = NCR_IDLE;
> /* Now ncr5380_sched() may be called again. */
> +
> + /* Check the queue. */
> + scsipi_channel_thaw(&sc->sc_channel, 0);
Why isn't it enough to do this, with or without the aborting
conditional?
+ const bool aborting = sc->sc_state & NCR_ABORTING;
+
/* Tell common SCSI code it is done. */
+ if (aborting)
+ scsipi_channel_freeze(&sc->sc_channel, 1);
scsipi_done(xs);
sc->sc_state = NCR_IDLE;
/* Now ncr5380_sched() may be called again. */
+
+ /* Check the queue if we were aborting. */
+ if (aborting)
+ scsipi_channel_thaw(&sc->sc_channel, 1);
The logic in scsipi_done now is essentially:
scsipi_done_once(...);
for (;;)/* scspi_run_queue */
mutex_enter(chan_mtx(chan));
if (chan->chan_qfreeze != 0) {
mutex_exit(chan_mtx(chan));
break;
}
...
}
And when scsipi_channel_thaw brings the freezecnt down to zero, it
does scsipi_run_queue.
So freezing the channel should have the same effect as
scsipi_done_once, and then thawing the channel should have the same
effect as scsipi_run_queue -- unless there is something else
interesting going on like a recursion of scsipi_done into itself in a
surprising place.
Re: CVS commit: src/usr.bin/env
> Date: Mon, 28 Oct 2024 22:17:31 - (UTC) > From: chris...@astron.com (Christos Zoulas) > > In article <20241028113037.b6b31f...@cvs.netbsd.org>, > Kimmo Suominen wrote: > >Implement "env -C dir" to chdir > > > >Use err(3) to expose errno(2) if chdir(2) (or unsetenv(3)) fails. > > We should just start from the FreeBSD copy I think because it has more > features. I'm not sure that `more features' is good... Some of these options are very clearly within the scope of env(1) and worthwhile, like -u -- it already has a way to set one variable, or to clear all variables, just not to clear one variable. -0 is reasonably necessary for the output to be reliable in all environments even if variables have embedded newlines. In contrast, processing /etc/login.conf (-L/-U) is not clearly a reasonable thing for a basic unprivileged tool like this to have baked into it. Having a special-purpose string formatter (-S) with substitutions strikes me as bizarre (why not just use printf or vis?). I'm having a hard time imagining where alternate path searching is important to bake into env(1) and not just into the caller, e.g. by doing `env -u PATH $(PATH=/altpath which foo) ...'.
Re: CVS commit: src/usr.bin/env
In article <20241028113037.b6b31f...@cvs.netbsd.org>, Kimmo Suominen wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: kim >Date: Mon Oct 28 11:30:37 UTC 2024 > >Modified Files: > src/usr.bin/env: env.1 env.c > >Log Message: >Implement "env -C dir" to chdir > >Use err(3) to expose errno(2) if chdir(2) (or unsetenv(3)) fails. We should just start from the FreeBSD copy I think because it has more features. christos
Re: CVS commit: src/sys
Yes, thanks Michael, this was all my fault because I made a last minute change. The code was correct before. christos > On Oct 7, 2024, at 9:17 AM, Rin Okuyama wrote: > > ATF failures seem to be fixed by mlelstv@: > https://mail-index.netbsd.org/source-changes/2024/10/06/msg153736.html > https://releng.netbsd.org/b5reports/i386/commits-2024.10.html#end > > Thanks, > rin > > On 2024/10/07 21:00, Christos Zoulas wrote: >> no, i did not. I will fix asap. >> christos >>> On Oct 6, 2024, at 7:59 PM, Taylor R Campbell wrote: >>> >>> Module Name:src Committed By: christos Date: Thu Oct 3 16:50:52 UTC 2024 Modified Files: src/sys/kern: syscalls.master sysv_sem.c src/sys/sys: sem.h Log Message: Add semtimedop GSoC 2024 (Shivraj Jamgade) >>> >>> This doesn't seem to pass the existing sysv semaphore tests: >>> >>> https://releng.netbsd.org/b5reports/i386/2024/2024.10.03.16.54.08/test.html#kernel_t_sysv_sem >>> https://mail-index.netbsd.org/current-users/2024/10/04/msg045666.html >>> >>> Did you run the tests before committing? >>> >>> None of the new tests seem to be passing either: >>> >>> https://releng.netbsd.org/b5reports/i386/2024/2024.10.04.05.56.03/test.html#failed-tcs-summary >>> >>> semtimedop_basic: >>> /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:77: >>> semtimedop failed: Invalid argument >>> semtimedop_invalid: >>> /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:249: >>> semtimedop did not fail on invalid sem_num >>> semtimedop_timeout: >>> /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:142: >>> WEXITSTATUS(status) != 0 signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/sys
ATF failures seem to be fixed by mlelstv@: https://mail-index.netbsd.org/source-changes/2024/10/06/msg153736.html https://releng.netbsd.org/b5reports/i386/commits-2024.10.html#end Thanks, rin On 2024/10/07 21:00, Christos Zoulas wrote: no, i did not. I will fix asap. christos On Oct 6, 2024, at 7:59 PM, Taylor R Campbell wrote: Module Name:src Committed By: christos Date: Thu Oct 3 16:50:52 UTC 2024 Modified Files: src/sys/kern: syscalls.master sysv_sem.c src/sys/sys: sem.h Log Message: Add semtimedop GSoC 2024 (Shivraj Jamgade) This doesn't seem to pass the existing sysv semaphore tests: https://releng.netbsd.org/b5reports/i386/2024/2024.10.03.16.54.08/test.html#kernel_t_sysv_sem https://mail-index.netbsd.org/current-users/2024/10/04/msg045666.html Did you run the tests before committing? None of the new tests seem to be passing either: https://releng.netbsd.org/b5reports/i386/2024/2024.10.04.05.56.03/test.html#failed-tcs-summary semtimedop_basic: /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:77: semtimedop failed: Invalid argument semtimedop_invalid: /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:249: semtimedop did not fail on invalid sem_num semtimedop_timeout: /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:142: WEXITSTATUS(status) != 0
Re: CVS commit: src/sys
no, i did not. I will fix asap. christos > On Oct 6, 2024, at 7:59 PM, Taylor R Campbell wrote: > > >> >> Module Name:src >> Committed By: christos >> Date: Thu Oct 3 16:50:52 UTC 2024 >> >> Modified Files: >>src/sys/kern: syscalls.master sysv_sem.c >>src/sys/sys: sem.h >> >> Log Message: >> Add semtimedop GSoC 2024 (Shivraj Jamgade) > > This doesn't seem to pass the existing sysv semaphore tests: > > https://releng.netbsd.org/b5reports/i386/2024/2024.10.03.16.54.08/test.html#kernel_t_sysv_sem > https://mail-index.netbsd.org/current-users/2024/10/04/msg045666.html > > Did you run the tests before committing? > > None of the new tests seem to be passing either: > > https://releng.netbsd.org/b5reports/i386/2024/2024.10.04.05.56.03/test.html#failed-tcs-summary > > semtimedop_basic: > /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:77: > semtimedop failed: Invalid argument > semtimedop_invalid: > /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:249: > semtimedop did not fail on invalid sem_num > semtimedop_timeout: > /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:142: > WEXITSTATUS(status) != 0
Re: CVS commit: src/sys
> Module Name:src > Committed By: christos > Date: Thu Oct 3 16:50:52 UTC 2024 > > Modified Files: > src/sys/kern: syscalls.master sysv_sem.c > src/sys/sys: sem.h > > Log Message: > Add semtimedop GSoC 2024 (Shivraj Jamgade) This doesn't seem to pass the existing sysv semaphore tests: https://releng.netbsd.org/b5reports/i386/2024/2024.10.03.16.54.08/test.html#kernel_t_sysv_sem https://mail-index.netbsd.org/current-users/2024/10/04/msg045666.html Did you run the tests before committing? None of the new tests seem to be passing either: https://releng.netbsd.org/b5reports/i386/2024/2024.10.04.05.56.03/test.html#failed-tcs-summary semtimedop_basic: /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:77: semtimedop failed: Invalid argument semtimedop_invalid: /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:249: semtimedop did not fail on invalid sem_num semtimedop_timeout: /tmp/build/2024.10.04.05.56.03-i386/src/tests/kernel/t_semtimedop.c:142: WEXITSTATUS(status) != 0
Re: CVS commit: src/sys/kern
On Sat, 5 Oct 2024, Michael van Elst wrote: Module Name:src Committed By: mlelstv Date: Sat Oct 5 18:04:53 UTC 2024 Modified Files: src/sys/kern: syscalls.master Log Message: New syscall requires SYSVSEM build option. Seems to me that the new syscall should be part of the SYSV module... +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: CVS commit: src/sys
Just wondering, should this be included in the SYSV_* module rather than in every kernel? On Thu, 3 Oct 2024, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Thu Oct 3 16:50:52 UTC 2024 Modified Files: src/sys/kern: syscalls.master sysv_sem.c src/sys/sys: sem.h Log Message: Add semtimedop GSoC 2024 (Shivraj Jamgade) To generate a diff of this commit: cvs rdiff -u -r1.313 -r1.314 src/sys/kern/syscalls.master cvs rdiff -u -r1.98 -r1.99 src/sys/kern/sysv_sem.c cvs rdiff -u -r1.35 -r1.36 src/sys/sys/sem.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:66fecb71142201951712202! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: CVS commit: src/lib/libc/include
> Module Name:src > Committed By: christos > Date: Sat Sep 28 14:24:59 UTC 2024 > > Modified Files: > src/lib/libc/include: extern.h > > Log Message: > need for __off_t in gnu11 mode. Why do we need to use __off_t in particular here? This file is purely internal to libc, right? So surely we can just use the normal off_t type, instead of the internal sys/ansi.h hack which exists to reduce namespace pollution. I think it is better if __off_t itself appears only in sys/ansi.h and the header files that use it to define off_t without polluting the namespace with anything else. (For that matter, not sure why we don't use _BSD_OFF_T_ like _BSD_SIZE_T_.)
Re: CVS commit: src/sys/compat/linux/common
> > This code could have done that - implemented linux's clone3() and then > redefined clone() to be a particular way of calling clone3() (which is > what I'd guess linux implementations might do, if they don't just have > both versions in full). That would have worked, but requires updating > the clone() implementation to be clone3() (even if on NetBSD lots of the > added stuff is simply meaningless). Stay tuned for that. Shivraj is working on it. christos signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/sys/compat/linux/common
Date:Mon, 30 Sep 2024 09:09:04 -0400 From:Christos Zoulas Message-ID: <2f4ec894-d66f-4608-84b1-7dd8433eb...@zoulas.com> | [quoting mrg@] | > this looks like it should use NETBSD32IPTR64(), No, that would be wrong (even if it happened to work), it is expecting to be given a 32 bit pointer (as an int) and converts that to a regular pointer for 64 bit arch's. Here we have 64 bit pointers (as integers) to be treated as 32 bit pointers (when built on a 32 bit arch). | See the comment in /usr/src/sys/compat/netbsd32/netbsd32.h: | | * NETBSD32_POINTER_TYPE | * - 32-bit pointer type, normally uint32_t but can be int32_t | *for platforms which rely on sign-extension of pointers | *such as SH-5. | *eg: #define NETBSD32_POINTER_TYPE uint32_t All of this is more or less assuming that the desire is to run 32 bit applications on a 64 bit system, which is no surprise, as that's what it is all for. What's happening in the file in question (linux compat mode) when running (or building) on i386 is taking a linux defined interface, defined to work for 64 bit systems (even when used on a 32 bit host), and running it on a 32 bit system. This is all more or less the direct opposite of what the netbsd32 compat stiff is designed for. It is even more messed up, as the code is trying to implement a new interface in terms of the older one it is to replace, which isn't something that is normally done. When an interface is enhanced, the usual practice is to redefine the older version in terms of the newer, with some form of default settings for the new features, so the new interface behaves the same way as the more limited older one would have. This code could have done that - implemented linux's clone3() and then redefined clone() to be a particular way of calling clone3() (which is what I'd guess linux implementations might do, if they don't just have both versions in full). That would have worked, but requires updating the clone() implementation to be clone3() (even if on NetBSD lots of the added stuff is simply meaningless). kre
Re: CVS commit: src/sys/compat/linux/common
> On Sep 29, 2024, at 10:27 PM, matthew green wrote: > > thanks for fixing the build. > > "Robert Elz" writes: >> Module Name: src >> Committed By:kre >> Date:Mon Sep 30 01:26:48 UTC 2024 >> >> Modified Files: >> src/sys/compat/linux/common: linux_sched.c >> >> Log Message: >> Supply a missing cast, which fixes the i386 (other 32 bit too probably) >> builds. >> >> Note I used uintptr_t rather than intptr_t which other similar >> lines nearby use - the int being converted to a ptr is uint64_t >> so using unsigned seemed safer to me. Feel free to change it. > > this looks like it should use NETBSD32IPTR64(), but that uses > intptr_t for reasons i don't recall but that may matter. maybe > we need better checking in general - does linux reject this one > 32-bit platforms if 'stack' has high half set, or perhaps the code > just assigns 64-bit input to a 32-it pointer and ignores them. > > christos? do you know? See the comment in /usr/src/sys/compat/netbsd32/netbsd32.h: * NETBSD32_POINTER_TYPE * - 32-bit pointer type, normally uint32_t but can be int32_t *for platforms which rely on sign-extension of pointers *such as SH-5. *eg: #define NETBSD32_POINTER_TYPE uint32_t And then: http://bxr.su/search?q=&defs=&refs=NETBSD32_POINTER_TYPE&path=&project=NetBSD mips and riscv use int32_t and the rest use uint32_t. christos signature.asc Description: Message signed with OpenPGP
re: CVS commit: src/sys/compat/linux/common
thanks for fixing the build. "Robert Elz" writes: > Module Name: src > Committed By: kre > Date: Mon Sep 30 01:26:48 UTC 2024 > > Modified Files: > src/sys/compat/linux/common: linux_sched.c > > Log Message: > Supply a missing cast, which fixes the i386 (other 32 bit too probably) > builds. > > Note I used uintptr_t rather than intptr_t which other similar > lines nearby use - the int being converted to a ptr is uint64_t > so using unsigned seemed safer to me. Feel free to change it. this looks like it should use NETBSD32IPTR64(), but that uses intptr_t for reasons i don't recall but that may matter. maybe we need better checking in general - does linux reject this one 32-bit platforms if 'stack' has high half set, or perhaps the code just assigns 64-bit input to a 32-it pointer and ignores them. christos? do you know? .mrg.
Re: CVS commit: src
On Tue, 24 Sep 2024 15:29:00 +0100 Jonathan A. Kollasch wrote --- > On Tue, Sep 24, 2024 at 05:15:41PM +0300, Valery Ushakov wrote: > > On Tue, Sep 24, 2024 at 13:03:30 +, Roy Marples wrote: > > > > > Take link state down: ifconfig vether0 link0 > > > Bring link state up: ifconfig vether0 -link0 > > > > Isn't that a bit counterintuitive that negation (-link0) means "up"? > > > > Perhaps... are you suggesting that link0 should be the default upon > vether clone-attach? Because I think the default state for a vether > link should probably be active.. You're both correct and I've adjusted accordingly. Thanks Roy
Re: CVS commit: src
On Tue, Sep 24, 2024 at 05:15:41PM +0300, Valery Ushakov wrote: > On Tue, Sep 24, 2024 at 13:03:30 +, Roy Marples wrote: > > > Take link state down: ifconfig vether0 link0 > > Bring link state up: ifconfig vether0 -link0 > > Isn't that a bit counterintuitive that negation (-link0) means "up"? > Perhaps... are you suggesting that link0 should be the default upon vether clone-attach? Because I think the default state for a vether link should probably be active..
Re: CVS commit: src
On Tue, Sep 24, 2024 at 13:03:30 +, Roy Marples wrote: > Take link state down: ifconfig vether0 link0 > Bring link state up: ifconfig vether0 -link0 Isn't that a bit counterintuitive that negation (-link0) means "up"? -uwe
Re: CVS commit: src
Date:Sat, 21 Sep 2024 20:48:51 + From:"Robert Elz" Message-ID: <20240921204851.18e75f...@cvs.netbsd.org> | In !TINYPROG versions of sh, make the builtin "shift" builtin command | perform a rotate instead or shift if given a numeric arg (which is | otherwise an error). Ugh ... that should have said In !TINYPROG versions of sh, make the shell "shift" builtin command perform a rotate instead of shift if given a negative arg (which is otherwise an error). kre
Re: CVS commit: src/sys/arch/i386/stand/lib
Hi, On 2024/09/19 3:33, Andrius V wrote: On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote: Module Name:src Committed By: rin Date: Wed Sep 18 00:44:03 UTC 2024 Modified Files: src/sys/arch/i386/stand/lib: libi386.h Log Message: i386/stand: Remove XMS leftover from libi386.h, NFC PR port-i386/58624 To generate a diff of this commit: cvs rdiff -u -r1.53 -r1.54 src/sys/arch/i386/stand/lib/libi386.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Thanks, not sure how it slipped (I have definitely seen the code, either forgot to copy to cvs directory or just forgot about it). It can be... Your work was otherwise perfect. Thank you very much for cleaning up things including tiny comments! rin
Re: CVS commit: src/sys/arch/i386/stand/lib
On Wed, Sep 18, 2024 at 3:44 AM Rin Okuyama wrote: > > Module Name:src > Committed By: rin > Date: Wed Sep 18 00:44:03 UTC 2024 > > Modified Files: > src/sys/arch/i386/stand/lib: libi386.h > > Log Message: > i386/stand: Remove XMS leftover from libi386.h, NFC > > PR port-i386/58624 > > > To generate a diff of this commit: > cvs rdiff -u -r1.53 -r1.54 src/sys/arch/i386/stand/lib/libi386.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > Thanks, not sure how it slipped (I have definitely seen the code, either forgot to copy to cvs directory or just forgot about it).
Re: CVS commit: src/sys/arch/mac68k/dev
Thank you very much for kind & rapid response!!
rin
On 2024/09/18 10:34, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Wed Sep 18 01:34:08 UTC 2024
Modified Files:
src/sys/arch/mac68k/dev: adb.c
Log Message:
The delay is only required for machines with built-in floppy drives.
I doubt the vibration from an external drive on the Duos would affect adb
before it attaches.
To generate a diff of this commit:
cvs rdiff -u -r1.61 -r1.62 src/sys/arch/mac68k/dev/adb.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/arch/mac68k/dev/adb.c
diff -u src/sys/arch/mac68k/dev/adb.c:1.61 src/sys/arch/mac68k/dev/adb.c:1.62
--- src/sys/arch/mac68k/dev/adb.c:1.61 Wed Sep 18 01:29:02 2024
+++ src/sys/arch/mac68k/dev/adb.c Wed Sep 18 01:34:08 2024
@@ -1,4 +1,4 @@
-/* $NetBSD: adb.c,v 1.61 2024/09/18 01:29:02 nat Exp $ */
+/* $NetBSD: adb.c,v 1.62 2024/09/18 01:34:08 nat Exp $ */
/*
* Copyright (C) 1994 Bradley A. Grantham
@@ -26,7 +26,7 @@
*/
#include
-__KERNEL_RCSID(0, "$NetBSD: adb.c,v 1.61 2024/09/18 01:29:02 nat Exp $");
+__KERNEL_RCSID(0, "$NetBSD: adb.c,v 1.62 2024/09/18 01:34:08 nat Exp $");
#include "opt_adb.h"
@@ -104,12 +104,6 @@ adbattach(device_t parent, device_t self
case MACH_MACPB180:
case MACH_MACPB180C:
case MACH_MACPB150:
- case MACH_MACPB210:
- case MACH_MACPB230:
- case MACH_MACPB250:
- case MACH_MACPB270:
- case MACH_MACPB280:
- case MACH_MACPB280C:
/* Reqired on machines with in-built trackballs. */
printf("... Waiting 5 seconds for adb devices to "
"settle.");
Re: CVS commit: src/sys/arch/mac68k/dev
Hi,
Can you please localize this quirk only for the affected machines?
It seems too much to me, to have 5 sec delay for irrelevant machines.
Thanks,
rin
On 2024/09/15 5:56, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Sat Sep 14 20:56:51 UTC 2024
Modified Files:
src/sys/arch/mac68k/dev: adb.c
Log Message:
Allow a few seconds for adb devices to settle.
The spin up of the floppy drive motor would cause a crash on my PowerBook
when adb was attached.
To generate a diff of this commit:
cvs rdiff -u -r1.59 -r1.60 src/sys/arch/mac68k/dev/adb.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/sys/arch/mac68k/dev/adb.c
diff -u src/sys/arch/mac68k/dev/adb.c:1.59 src/sys/arch/mac68k/dev/adb.c:1.60
--- src/sys/arch/mac68k/dev/adb.c:1.59 Sat Aug 7 16:18:57 2021
+++ src/sys/arch/mac68k/dev/adb.c Sat Sep 14 20:56:50 2024
@@ -1,4 +1,4 @@
-/* $NetBSD: adb.c,v 1.59 2021/08/07 16:18:57 thorpej Exp $ */
+/* $NetBSD: adb.c,v 1.60 2024/09/14 20:56:50 nat Exp $ */
/*
* Copyright (C) 1994 Bradley A. Grantham
@@ -26,7 +26,7 @@
*/
#include
-__KERNEL_RCSID(0, "$NetBSD: adb.c,v 1.59 2021/08/07 16:18:57 thorpej Exp $");
+__KERNEL_RCSID(0, "$NetBSD: adb.c,v 1.60 2024/09/14 20:56:50 nat Exp $");
#include "opt_adb.h"
@@ -94,6 +94,9 @@ static void
adbattach(device_t parent, device_t self, void *aux)
{
+ printf("... Waiting 5 seconds for adb devices to settle.");
+ kpause("adb-slp", false, mstohz(5000), NULL);
+
adb_softintr_cookie = softint_establish(SOFTINT_SERIAL,
(void (*)(void *))adb_soft_intr, NULL);
printf("\n");
Re: CVS commit: src/sys/arch/x86/x86
On Wed, Sep 11, 2024 at 05:17:45 +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Wed Sep 11 05:17:45 UTC 2024
>
> Modified Files:
> src/sys/arch/x86/x86: intr.c
>
> Log Message:
> apply some more diagnostic checks for x86 interrupts
How does this mix with KDTRACE_HOOKS? To paraphrase:
#define IS_I8254_CLOCKINTR \
(handler == __FPTRCAST(int (*)(void *), i8254_clockintr))
#ifdef KDTRACE_HOOKS
if (!IS_I8254_CLOCKINTR) {
ih->ih_fun = intr_kdtrace_wrapper;
ih->ih_arg = ih;
}
#endif
#ifdef MULTIPROCESSOR
if (!mpsafe) {
KASSERT(!IS_I8254_CLOCKINTR);
ih->ih_fun = intr_biglock_wrapper;
ih->ih_arg = ih;
}
#ifdef DIAGNOSTIC /* wrap all interrupts */
else if (!IS_I8254_CLOCKINTR) {
ih->ih_fun = intr_wrapper;
ih->ih_arg = ih;
}
#endif
#endif /* MULTIPROCESSOR */
and MULTIPROCESSOR case overwrites whatever KDTRACE_HOOKS did, doesn't
it?
-uwe
Re: CVS commit: src/lib/libc
> Date: Sat, 14 Sep 2024 22:26:37 - (UTC) > From: chris...@astron.com (Christos Zoulas) > > In article , > Thomas Klausner wrote: > >On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote: > >> POSIX.1-2024 removes asctime_r and ctime_r and does not let > >> libraries define them, so remove them except when needed to > >> conform to earlier POSIX. These functions are dangerous as they > >> can overrun user buffers. If you still need them, add > >> -DSUPPORT_POSIX2008 to CFLAGS. > > > >Hm, that sounds like we should hide asctime_r and ctime_r? > > I think that it will break stuff in pkgsrc... We could, I guess. We have to continue defining the symbols in libc. We can put the declarations in time.h under #if (_POSIX_C_SOURCE - 0 < 202405L) || defined(_NETBSD_SOURCE) ... #endif in addition to whatever conditions are already there. The _POSIX_C_SOURCE part is mandatory for POSIX.1-2024 compliance. The _NETBSD_SOURCE part is up to us and we could choose to remove it later (or invent a date system for _NETBSD_SOURCE like _POSIX_C_SOURCE), or, rather, replace it by __LIBC12_SOURCE__ so the libc definitions still work.
Re: CVS commit: src/lib/libc
chris...@astron.com (Christos Zoulas) writes: >>> POSIX.1-2024 removes asctime_r and ctime_r and does not let >>> libraries define them, so remove them except when needed to >>> conform to earlier POSIX. These functions are dangerous as they >>> can overrun user buffers. If you still need them, add >>> -DSUPPORT_POSIX2008 to CFLAGS. >> >>Hm, that sounds like we should hide asctime_r and ctime_r? >> > > I think that it will break stuff in pkgsrc... We could, I guess. Visisbility define use is a nice theory but in practice it's a mess. Probably, before hiding, someone(tm) should build a system with them hidden and do a bulk build. More seriously, NetBSD having breaking changes generally does not go well, unless Linux has had the change for a year, so that upstreams have had time to adapt.
Re: CVS commit: src/lib/libc
In article , Thomas Klausner wrote: >On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Wed Sep 11 13:50:35 UTC 2024 >> >> Modified Files: >> src/lib/libc/compat/time: compat_localtime.c >> src/lib/libc/time: CONTRIBUTING Makefile Makefile.inc NEWS asctime.c >> localtime.c private.h theory.html tz-art.html tz-link.html tzfile.5 >> tzselect.ksh version zdump.c zic.8 zic.c >> >> Log Message: >> Merge tzcode-2024b >> >> Release 2024b - 2024-09-04 12:27:47 -0700 >> >> Changes to code >> >> localtime.c now always uses a TZif file's time type 0 to handle >> timestamps before the file's first transition. Formerly, >> localtime.c sometimes inferred a different time type, in order to >> handle problematic data generated by zic 2018e or earlier. As it >> is now safe to assume more recent versions of zic, there is no >> longer a pressing need to fail to conform RFC 8536 section 3.2, >> which requires using time type 0 in this situation. This change >> does not affect behavior when reading TZif files generated by zic >> 2018f and later. >> >> POSIX.1-2024 removes asctime_r and ctime_r and does not let >> libraries define them, so remove them except when needed to >> conform to earlier POSIX. These functions are dangerous as they >> can overrun user buffers. If you still need them, add >> -DSUPPORT_POSIX2008 to CFLAGS. > >Hm, that sounds like we should hide asctime_r and ctime_r? > I think that it will break stuff in pkgsrc... We could, I guess. christos
Re: CVS commit: src/sys/miscfs/procfs
This was also supposed to include in the log message: Include mqueue-based entries only if built with MQUEUE option. On Sat, 14 Sep 2024, Paul Goyette wrote: Module Name:src Committed By: pgoyette Date: Sat Sep 14 01:37:42 UTC 2024 Modified Files: src/sys/miscfs/procfs: procfs_linux.c procfs_vfsops.c Log Message: Define dependencies based on build options. To generate a diff of this commit: cvs rdiff -u -r1.89 -r1.90 src/sys/miscfs/procfs/procfs_linux.c cvs rdiff -u -r1.119 -r1.120 src/sys/miscfs/procfs/procfs_vfsops.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. !DSPAM:66e4e8e8182295181515653! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: CVS commit: src/sys/sys
Hi, Christos Zoulas writes: > And committed. Thank you very much for your quick fix. It works fine for me now. > christos > > -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/lib/libc
On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Sep 11 13:50:35 UTC 2024 > > Modified Files: > src/lib/libc/compat/time: compat_localtime.c > src/lib/libc/time: CONTRIBUTING Makefile Makefile.inc NEWS asctime.c > localtime.c private.h theory.html tz-art.html tz-link.html tzfile.5 > tzselect.ksh version zdump.c zic.8 zic.c > > Log Message: > Merge tzcode-2024b > > Release 2024b - 2024-09-04 12:27:47 -0700 > > Changes to code > > localtime.c now always uses a TZif file's time type 0 to handle > timestamps before the file's first transition. Formerly, > localtime.c sometimes inferred a different time type, in order to > handle problematic data generated by zic 2018e or earlier. As it > is now safe to assume more recent versions of zic, there is no > longer a pressing need to fail to conform RFC 8536 section 3.2, > which requires using time type 0 in this situation. This change > does not affect behavior when reading TZif files generated by zic > 2018f and later. > > POSIX.1-2024 removes asctime_r and ctime_r and does not let > libraries define them, so remove them except when needed to > conform to earlier POSIX. These functions are dangerous as they > can overrun user buffers. If you still need them, add > -DSUPPORT_POSIX2008 to CFLAGS. Hm, that sounds like we should hide asctime_r and ctime_r? Thomas
Re: CVS commit: src/sys/sys
And committed. christos
Re: CVS commit: src/sys/sys
On 2024-09-11 11:18 am, Taylor R Campbell wrote: Date: Thu, 12 Sep 2024 00:05:24 +0900 From: Ryo ONODERA "Taylor R Campbell" writes: > sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE. > > These are non-standard extensions, so they should not be exposed by, > e.g., _XOPEN_SOURCE=700. > > PR standards/57807: #include spuriously defines > le32enc/be32enc/... under _XOPEN_SOURCE=700 After this change, -current build on -current is broken, because tools/libctf defines _NETBSD_SOURCE and le32dec and so on cause conflicts. I think HAVE_NBTOOLS_CONFIG_H part in external/cddl/osnet/sys/sys/types.h may be problematic. However it is not clear how to fix properly. Could you take a look at this problem? christos was looking at this yesterday -- christos, did you make progress after our discussion? P.S. I feel that HAVE_NBTOOLS_CONFIG_H should be HAVE_NBTOOL_CONFIG_H. Yes, except I think that whole stanza under HAVE_NBTOOL[S]_CONFIG_H is wrong and should be replaced by an _unconditional_ #include_next #include_next without any _NETBSD_SOURCE games (which the tools build should never play; we go out of our way to use _XOPEN_SOURCE=600 in compat_defs.h so that _NETBSD_SOURCE does not get used everywhere else in the tools build, in order to keep the tools build clean and portable). Yes, close to finish the build and commit changes. -- christos
Re: CVS commit: src/sys/sys
> Date: Thu, 12 Sep 2024 00:05:24 +0900 > From: Ryo ONODERA > > "Taylor R Campbell" writes: > > > sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE. > > > > These are non-standard extensions, so they should not be exposed by, > > e.g., _XOPEN_SOURCE=700. > > > > PR standards/57807: #include spuriously defines > > le32enc/be32enc/... under _XOPEN_SOURCE=700 > > After this change, -current build on -current is broken, > because tools/libctf defines _NETBSD_SOURCE and le32dec and so on > cause conflicts. > > I think HAVE_NBTOOLS_CONFIG_H part in external/cddl/osnet/sys/sys/types.h > may be problematic. However it is not clear how to fix properly. > > Could you take a look at this problem? christos was looking at this yesterday -- christos, did you make progress after our discussion? > P.S. > I feel that HAVE_NBTOOLS_CONFIG_H should be HAVE_NBTOOL_CONFIG_H. Yes, except I think that whole stanza under HAVE_NBTOOL[S]_CONFIG_H is wrong and should be replaced by an _unconditional_ #include_next #include_next without any _NETBSD_SOURCE games (which the tools build should never play; we go out of our way to use _XOPEN_SOURCE=600 in compat_defs.h so that _NETBSD_SOURCE does not get used everywhere else in the tools build, in order to keep the tools build clean and portable).
Re: CVS commit: src/sys/sys
Hi, "Taylor R Campbell" writes: > Module Name: src > Committed By: riastradh > Date: Mon Sep 9 18:17:14 UTC 2024 > > Modified Files: > src/sys/sys: endian.h > > Log Message: > sys/endian.h: Hide le32enc/be32enc/... under _NETBSD_SOURCE. > > These are non-standard extensions, so they should not be exposed by, > e.g., _XOPEN_SOURCE=700. > > PR standards/57807: #include spuriously defines > le32enc/be32enc/... under _XOPEN_SOURCE=700 After this change, -current build on -current is broken, because tools/libctf defines _NETBSD_SOURCE and le32dec and so on cause conflicts. I think HAVE_NBTOOLS_CONFIG_H part in external/cddl/osnet/sys/sys/types.h may be problematic. However it is not clear how to fix properly. Could you take a look at this problem? P.S. I feel that HAVE_NBTOOLS_CONFIG_H should be HAVE_NBTOOL_CONFIG_H. Thank you. > To generate a diff of this commit: > cvs rdiff -u -r1.33 -r1.34 src/sys/sys/endian.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Modified files: > > Index: src/sys/sys/endian.h > diff -u src/sys/sys/endian.h:1.33 src/sys/sys/endian.h:1.34 > --- src/sys/sys/endian.h:1.33 Mon Sep 9 15:22:50 2024 > +++ src/sys/sys/endian.h Mon Sep 9 18:17:14 2024 > @@ -1,4 +1,4 @@ > -/* $NetBSD: endian.h,v 1.33 2024/09/09 15:22:50 riastradh Exp $*/ > +/* $NetBSD: endian.h,v 1.34 2024/09/09 18:17:14 riastradh Exp $*/ > > /* > * Copyright (c) 1987, 1991, 1993 > @@ -192,6 +192,8 @@ __END_DECLS > * to/from an octet stream. > */ > > +#ifdef _NETBSD_SOURCE > + > #if __GNUC_PREREQ__(2, 95) > > #define __GEN_ENDIAN_ENC(bits, endian) \ > @@ -337,6 +339,8 @@ le64dec(const void *buf) > > #endif /* GCC >= 2.95 */ > > +#endif /* _NETBSD_SOURCE */ > + > #endif /* !_LOCORE */ > #endif /* _XOPEN_SOURCE || _NETBSD_SOURCE */ > #endif /* !_SYS_ENDIAN_H_ */ > -- Ryo ONODERA // r...@tetera.org PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/distrib/sets/lists/base
Date:Sun, 8 Sep 2024 22:35:02 + From:"Robert Elz" Message-ID: <20240908223502.927a4f...@cvs.netbsd.org> | Modified Files: | src/distrib/sets/lists/base: mi | | Log Message: | One more mozilla-rootcerts file that is now obsolete. | This fixes one current build breakage, but there is more to come. Actually, fixed all of it - the remainder I was seeing was just the typical breakage from an update build in the distrib//cdroms directory, where something that goes on the cdrom is altered (the mozilla rootcerts this time, but it can be anything) in such a way that files are added or deleted, there are no rules to cause the cdrom spec.fs to be rebuilt in such a case, and consequently the build fails. We need to fix this sometime, even if it is just an "if this fails, do a make clean, and try again" in those directories. kre
Re: CVS commit: src/sys/dev/pci
On Wed, Aug 21, 2024 at 01:42:28AM -0700, John Nemeth wrote: > } Log Message: > } Add Areca ARC-1224 > > I noticed that you mentioned newer Areca devices on icb. Is > there a particular device that you're interested in. I have an > updated version of arcmsr(4) that I've been meaning to clean up > and commit. It has been tested with at least one device newer than > what the in-tree code has. It was mostly done with code that Areca > provided with some cleanup by myself (especially the error paths). I was interested in perhaps importing or integrating at least some of the Areca-provided driver sources - but actual work on that on my part has been limited to eyeballing the diffs and wondering whether there were a cleaner way to integrate the five different variants that it supports (and the accompanying 2x size increase in both the header and .c files). It sounds like you're way, way further along than I am - if you were willing and able to commit, I'd heartily encourage you to do so. (I do *not* have any of the newer devices in question, FWIW. I'd also note that the FreeBSD driver for the non-SAS cards looks radically different from arcmsr and also requires linking in a binary blob, alas.)
Re: CVS commit: src/sys/dev/pci
On Aug 20, 22:44, "Tom Spindler" wrote: } } Module Name: src } Committed By: dogcow } Date: Tue Aug 20 22:44:04 UTC 2024 } } Modified Files: } src/sys/dev/pci: pcidevs } } Log Message: } Add Areca ARC-1224 Hi Tom, I noticed that you mentioned newer Areca devices on icb. Is there a particular device that you're interested in. I have an updated version of arcmsr(4) that I've been meaning to clean up and commit. It has been tested with at least one device newer than what the in-tree code has. It was mostly done with code that Areca provided with some cleanup by myself (especially the error paths). }-- End of excerpt from "Tom Spindler"
Re: CVS commit: src/lib/libc/locale
> Date: Sun, 18 Aug 2024 19:55:10 +0200 > From: Roland Illig > > Am 18.08.2024 um 15:39 schrieb Taylor R Campbell: > > Please revert the casts and use `LINTFLAGS.mbrtoc8.c+= -X 132' instead > > until it is fixed. > > It is fixed. Awesome, thanks!
Re: CVS commit: src/lib/libc/locale
Am 18.08.2024 um 15:39 schrieb Taylor R Campbell: >> Date: Sat, 17 Aug 2024 17:55:28 -0400 >> From: Christos Zoulas >> >> There is only one bug. I have sent mail to Roland about it and will revert >> once it is fixed. >> >> The rest are: >> - cast through (void *) >> - add casts because __BITS returns uintmax_t which is wider than the >> destination types. > > To track this bug, I filed PR toolchain/58617: lint spuriously warns > about impossible __SHIFTOUT/__BITS truncation > (https://gnats.NetBSD.org/58617). > > Please revert the casts and use `LINTFLAGS.mbrtoc8.c+= -X 132' instead > until it is fixed. It is fixed.
Re: CVS commit: src/lib/libc/locale
> Date: Sat, 17 Aug 2024 17:55:28 -0400 > From: Christos Zoulas > > There is only one bug. I have sent mail to Roland about it and will revert > once it is fixed. > > The rest are: > - cast through (void *) > - add casts because __BITS returns uintmax_t which is wider than the > destination types. To track this bug, I filed PR toolchain/58617: lint spuriously warns about impossible __SHIFTOUT/__BITS truncation (https://gnats.NetBSD.org/58617). Please revert the casts and use `LINTFLAGS.mbrtoc8.c+= -X 132' instead until it is fixed.
Re: CVS commit: src/lib/libc/locale
Hi, For __CTASSERT v.s. case label: https://nxr.netbsd.org/xref/src/lib/libc/locale/c8rtomb.c#225 not only lint(1), but also GCC 10.5 does not accept this, which results in build failures for platforms still using gcc.old: https://releng.netbsd.org/builds/HEAD/202408171750Z/ Can we just drop this __CTASSERT, as the same condition is already asserted several lines above?: https://nxr.netbsd.org/xref/src/lib/libc/locale/c8rtomb.c#195 Thanks, rin
Re: CVS commit: src/distrib/sets/lists/man
Done :) Thanks for your kind words! rin On 2024/08/17 3:41, Christos Zoulas wrote: Rin, thank you so much for working on this. LG[reat]TM. Please commit. christos On Aug 16, 2024, at 6:06 AM, Rin Okuyama wrote: Hi, I've changed mknative-gdb to generate *.info by using makeinfo(1) provided by pkgsrc-2024Q2: https://github.com/IIJ-NetBSD/netbsd-src/compare/master...rokuyama:netbsd-src:exp/mknative-gdb-makeinfo Then, pre-generated infos are installed for normal builds. Also, in this branch: - Add some missing documents - Introduce MKGDBSERVER for clarity - Similar changes for gdb.old, but continue to build *.info every time for normal builds Thoughts? Thanks, rin On 2024/08/16 10:02, Paul Goyette wrote: On Thu, 15 Aug 2024, Christos Zoulas wrote: Module Name:src Committed By:christos Date:Thu Aug 15 21:51:35 UTC 2024 Modified Files: src/distrib/sets/lists/man: mi Log Message: sigh, no more info files for gdb. Can we please try and find someone to package up the info files into pkgsrc? It would be a real shame to not have docs... +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: CVS commit: src/lib/libc/locale
> Date: Sat, 17 Aug 2024 17:55:28 -0400 > From: Christos Zoulas > > There is only one bug. I have sent mail to Roland about it and will revert > once it is fixed. > > The rest are: > - cast through (void *) There is no need to cast through (void *) -- not in C, not in KNF, and not for any other reason I know of. It's not a big deal to leave in, but it's also unnecessary clutter and I would rather remove it. > - add casts because __BITS returns uintmax_t which is wider than the > destination types. I'm sympathetic to the proposition that implicit integer conversions can conceal scary bugs in C. But in this case, the output is trivially guaranteed to lie within the desired range, so it is obvious that the integer conversion never loses anything even though the intermediate types are larger -- that's a big part of the point of the convenience and legibility of __BITS and __SHIFTIN/__SHIFTOUT. If lint complains because it can't figure this out, that's a lint bug. And the casts make the code much harder to read. Please revert this and let's make lint serve our needs, not make us serve lint's needs. if (pc8) *pc8 = 0xf0 | __SHIFTOUT(c32, __BITS(20,18)); S->buf[0] = 0x80 | __SHIFTOUT(c32, __BITS(17,12)); S->buf[1] = 0x80 | __SHIFTOUT(c32, __BITS(11,6)); S->buf[2] = 0x80 | __SHIFTOUT(c32, __BITS(5,0)); versus if (pc8) *pc8 = (char8_t)( 0xf0 | __SHIFTOUT(c32, __BITS(20,18))); S->buf[0] = (char8_t)( 0x80 | __SHIFTOUT(c32, __BITS(17,12))); S->buf[1] = (char8_t)( 0x80 | __SHIFTOUT(c32, __BITS(11,6))); S->buf[2] = (char8_t)( 0x80 | __SHIFTOUT(c32, __BITS(5,0)));
Re: CVS commit: src/lib/libc/locale
There is only one bug. I have sent mail to Roland about it and will revert once it is fixed. The rest are: - cast through (void *) - add casts because __BITS returns uintmax_t which is wider than the destination types. christos > On Aug 17, 2024, at 5:29 PM, Taylor R Campbell wrote: > >> Module Name:src >> Committed By: christos >> Date: Sat Aug 17 20:08:13 UTC 2024 >> >> Modified Files: >>src/lib/libc/locale: c16rtomb.c c8rtomb.c mbrtoc16.c mbrtoc32.c >>mbrtoc8.c >> >> Log Message: >> pass lint, XXX see lint bug. > > Can you please arrange to fix the lint bugs, and revert this clutter?
Re: CVS commit: src/lib/libc/locale
> Module Name:src > Committed By: christos > Date: Sat Aug 17 20:08:13 UTC 2024 > > Modified Files: > src/lib/libc/locale: c16rtomb.c c8rtomb.c mbrtoc16.c mbrtoc32.c > mbrtoc8.c > > Log Message: > pass lint, XXX see lint bug. Can you please arrange to fix the lint bugs, and revert this clutter?
