Re: CVS commit: src/sys
What issue is this change attempting to resolve? > On May 20, 2024, at 4:34 AM, Taylor R Campbell wrote: > > Module Name: src > Committed By: riastradh > Date: Mon May 20 11:34:19 UTC 2024 > > Modified Files: > src/sys/arch/sparc64/dev: pci_machdep.c > src/sys/arch/sparc64/include: pci_machdep.h > src/sys/arch/xen/include: pci_machdep.h > src/sys/arch/xen/xen: xpci_xenbus.c > src/sys/dev/acpi: acpi_mcfg.c > src/sys/dev/pci: pci.c pcivar.h > > Log Message: > pci: Pass cookie through pci_find_device, pci_enumerate_bus. > > New functions pci_find_device1 and pci_enumerate_bus1 have the cookie > argument. Existing symbols pci_find_device and pci_enumerate_bus are > now wrappers for the cookieless version. > > This drops the symbol pci_probe_device, in favour of a new > pci_probe_device1 with the cookie argument. But I don't think that > requires a revbump because it's only called by MD pci_enumerate_bus1 > implementations, which don't live in modules anyway. > > > To generate a diff of this commit: > cvs rdiff -u -r1.80 -r1.81 src/sys/arch/sparc64/dev/pci_machdep.c > cvs rdiff -u -r1.28 -r1.29 src/sys/arch/sparc64/include/pci_machdep.h > cvs rdiff -u -r1.21 -r1.22 src/sys/arch/xen/include/pci_machdep.h > cvs rdiff -u -r1.26 -r1.27 src/sys/arch/xen/xen/xpci_xenbus.c > cvs rdiff -u -r1.26 -r1.27 src/sys/dev/acpi/acpi_mcfg.c > cvs rdiff -u -r1.165 -r1.166 src/sys/dev/pci/pci.c > cvs rdiff -u -r1.117 -r1.118 src/sys/dev/pci/pcivar.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src/usr.bin/make
Taylor R Campbell wrote: > Can you please back this out promptly, add automatic tests for > whatever the underlying issue is, and redo it another way? I did a scan of miss-use of <>, and looks like libc might have an issue: lib/libc/arch/arm/Makefile.inc:28:.include expects to find lib/libc/softfloat/Makefile.inc via .CURDIR, so have re-enabled that search.
re: CVS commit: src
thanks for this fix. > Modified Files: > src/external/gpl3/gcc/dist/libstdc++-v3/config/io: basic_file_stdio.cc probably want to apply this fix to gcc.old, and also consider pullup-10 (and pullup-9, if similar?), since gcc.old is the currently used compiler in current. .mrg.
Re: CVS commit: src/usr.bin/make
Taylor R Campbell wrote: > > --- cleandir-libterminfo --- > nbmake[5]: "/tmp/build/2024.05.19.20.09.40-i386/src/lib/libterminfo/Makefile" > line 50: Could not find Makefile.hash > > Can you please back this out promptly, add automatic tests for > whatever the underlying issue is, and redo it another way? Sorry, for the break. The makefile in lib/libterminfo was using <> when it should use "". Martin already fixed it. I'm checking for similar
Re: CVS commit: src/usr.bin/make
> Module Name:src > Committed By: sjg > Date: Sun May 19 20:09:40 UTC 2024 > > Modified Files: > src/usr.bin/make: dir.c dir.h parse.c > > Log Message: > make: use separate function to include makefiles. > > Have Dir_FindFile and Dir_FindInclude call FindFile with a > bool flag to indicate whether .CURDIR should be be searched at all. This appears to have broken all of the builds: https://releng.netbsd.org/builds/HEAD/202405200920Z/ https://releng.netbsd.org/b5reports/i386/commits-2024.05.html#2024.05.19.20.09.40 https://releng.netbsd.org/b5reports/i386/2024/2024.05.19.20.09.40/build.log.tail --- cleandir-libterminfo --- nbmake[5]: "/tmp/build/2024.05.19.20.09.40-i386/src/lib/libterminfo/Makefile" line 50: Could not find Makefile.hash Can you please back this out promptly, add automatic tests for whatever the underlying issue is, and redo it another way?
Re: CVS commit: src
> On May 19, 2024, at 6:21 PM, Christos Zoulas wrote: > > We discussed it with Taylor and decided to call it dup3100 after all since > we've > already followed the old scheme for kevent100 and it is better to be > consistent > for the 11 release.We can start calling new syscalls 12 after 11 is released. But how can the old one be in compat_11? -- thorpej
Re: CVS commit: src
> On May 19, 2024, at 9:19 PM, Jason Thorpe wrote: > > >> On May 19, 2024, at 5:35 PM, Christos Zoulas wrote: >> >> In article <9c72736d-707b-4267-bd05-45bffea52...@me.com>, >> Jason Thorpe wrote: >>> >>> On May 19, 2024, at 3:25 PM, Christos Zoulas wrote: src/sys/compat/common: compat_110_mod.c sys_decrip_110.c src/sys/compat/netbsd32: netbsd32_compat_110.c src/sys/conf: compat_netbsd110.config src/sys/modules/compat_110: Makefile src/sys/modules/compat_netbsd32_110: Makefile >>> >>> Wait, why is there now a compat_110 module? netbsd-11 isn’t out yet. >>> dup3() belongs in the compat_100 module. >> >> You asked for the syscall to be called dup3110 so I put it in compat_110... > > The new system call is dup3110 (“dup3 for 11.0”), the old one is “netbsd-10 > compatibility”, so belongs in compat_10. > We discussed it with Taylor and decided to call it dup3100 after all since we've already followed the old scheme for kevent100 and it is better to be consistent for the 11 release.We can start calling new syscalls 12 after 11 is released. christos
Re: CVS commit: src
> On May 19, 2024, at 5:35 PM, Christos Zoulas wrote: > > In article <9c72736d-707b-4267-bd05-45bffea52...@me.com>, > Jason Thorpe wrote: >> >> >>> On May 19, 2024, at 3:25 PM, Christos Zoulas wrote: >>> >>> src/sys/compat/common: compat_110_mod.c sys_decrip_110.c >>> src/sys/compat/netbsd32: netbsd32_compat_110.c >>> src/sys/conf: compat_netbsd110.config >>> src/sys/modules/compat_110: Makefile >>> src/sys/modules/compat_netbsd32_110: Makefile >> >> Wait, why is there now a compat_110 module? netbsd-11 isn’t out yet. >> dup3() belongs in the compat_100 module. > > You asked for the syscall to be called dup3110 so I put it in compat_110... The new system call is dup3110 (“dup3 for 11.0”), the old one is “netbsd-10 compatibility”, so belongs in compat_10. -- thorpej
Re: CVS commit: src
In article <9c72736d-707b-4267-bd05-45bffea52...@me.com>, Jason Thorpe wrote: > > >> On May 19, 2024, at 3:25â¯PM, Christos Zoulas wrote: >> >> src/sys/compat/common: compat_110_mod.c sys_decrip_110.c >> src/sys/compat/netbsd32: netbsd32_compat_110.c >> src/sys/conf: compat_netbsd110.config >> src/sys/modules/compat_110: Makefile >> src/sys/modules/compat_netbsd32_110: Makefile > >Wait, why is there now a compat_110 module? netbsd-11 isnât out yet. >dup3() belongs in the compat_100 module. You asked for the syscall to be called dup3110 so I put it in compat_110... christos
Re: CVS commit: src
> On May 19, 2024, at 3:25 PM, Christos Zoulas wrote: > > src/sys/compat/common: compat_110_mod.c sys_decrip_110.c > src/sys/compat/netbsd32: netbsd32_compat_110.c > src/sys/conf: compat_netbsd110.config > src/sys/modules/compat_110: Makefile > src/sys/modules/compat_netbsd32_110: Makefile Wait, why is there now a compat_110 module? netbsd-11 isn’t out yet. dup3() belongs in the compat_100 module. -- thorpej
Re: CVS commit: src/share/man/man4
On Thu, May 16, 2024 at 05:48:05PM +0300, Valery Ushakov wrote: > On Thu, May 16, 2024 at 11:54:20 +, Nia Alarie wrote: > > > Modified Files: > > src/share/man/man4: eap.4 > > > > Log Message: > > Note that EAP_USE_BOTH_DACS is deprecated in the eap(4) manual page. > > Please, can you restore the part that explains what this option > is/does? It might be on its way out, but since we document it's > there, it's a good idea to actually document it, IMHO. > > I don't know much about audio, but the kernel mixer is software, isn't > it. I would imagine the type of systems that might have this device > may actually benefit from the hardware acceleration that this option > seems to imply. > > I.e. if anything, I'd rather this option is documented even better > than it was. Let me know if the new version of the text leaves any doubts.
Re: CVS commit: src/share/man/man4
On Thu, May 16, 2024 at 11:54:20 +, Nia Alarie wrote: > Modified Files: > src/share/man/man4: eap.4 > > Log Message: > Note that EAP_USE_BOTH_DACS is deprecated in the eap(4) manual page. Please, can you restore the part that explains what this option is/does? It might be on its way out, but since we document it's there, it's a good idea to actually document it, IMHO. I don't know much about audio, but the kernel mixer is software, isn't it. I would imagine the type of systems that might have this device may actually benefit from the hardware acceleration that this option seems to imply. I.e. if anything, I'd rather this option is documented even better than it was. -uwe
Re: CVS commit: src/bin/echo
Date:Wed, 15 May 2024 02:33:23 +0300 From:Valery Ushakov Message-ID: | I vaguely remember I read somewhere that printf(1) was specifically | conceived to take no options, but that can be planted memories. May | be it's indeed induced by the old state of affairs in our version. POSIX printf(1) has no options (it says in its page "OPTIONS: None") and our printf has no options, but implementations are allowed to extend the standard, and add some, POSIX says (XCU 1.4) that when it says "OPTIONS: None" what it means is: Default Behavior: When this section is listed as ``None.'', it means that the implementation need not support any options. Standard utilities that do not accept options, but that do accept operands, shall recognize "--" as a first argument to be discarded. That is more or less what we do, but for backwards compat reasons, not always. The requirement for recognizing "--" is because conforming applications need a way to shield their operands from any arbitrary options that the implementation may provide as an extension. For example, if the standard utility foo is listed as taking no options, and the application needed to give it a pathname with a leading , it could safely do it as: foo -- -myfile and avoid any problems with -m used as an extension. Other versions of printf(1) do have options, or at least, an option. bash, ksh93 & zsh all have a "-v var" option to cause the output from (the builtin) printf to be stored in var, rather than written to stdout. It might be time to adjust our ptintf to be fully POSIX, and always handle the "--" end of options option (it doesn't seem useful as a printf format, and if needed, can always be written as printf -- --) rather than only doing it sometimes. Currently our printf used as "printf --" writes "--" to stdout. It really shouldn't. When there is just 1 arg, and it contains no %, it is also treated as a format, even if it starts with a '-'. So, as you demonstrated, in our printf, printf -V prints "-V", but if you try 'printf -V A B C' what you get is: sh: unknown option -- V Usage: printf format [arg ...] (It would do the same if given a script with one of the -v var options used in it). The comments at the start of main() in our printf(1) source are nonsense (though for backwards compat, we should just check for "--" rather than using getopt() to do that for us, as we currently do, when we do it.) kre ps: I do appreciate that some of the mess that is there now is my doing, but back when I did that I didn't understand POSIX as well as I do now.
Re: CVS commit: src/bin/echo
On Wed, May 15, 2024 at 05:22:25 +0700, Robert Elz wrote: > | Unfortunately that advice is not true without further caveats. > > That you have to actually write a valid printf(1) command, and not > simply s/echo/printf/ ? Does that really need saying? > > > | netbsd$ sh -c "printf '-V\n'" > > printf -- -V\\n > > and it will work anywhere - our printf is specially hacked as once > upon a time it took no options, and this kind of thing would work. > Format strings starting with a '-' don't work in general however, > the '--' should be included if the format might begin with a '-'. > > Even better would be > > printf -- %s\\n -V > > (where the -- is optional here). I vaguely remember I read somewhere that printf(1) was specifically conceived to take no options, but that can be planted memories. May be it's indeed induced by the old state of affairs in our version. -uwe
Re: CVS commit: src/bin/echo
Date:Tue, 14 May 2024 12:41:51 +0300 From:Valery Ushakov Message-ID: | Unfortunately that advice is not true without further caveats. That you have to actually write a valid printf(1) command, and not simply s/echo/printf/ ? Does that really need saying? | netbsd$ sh -c "printf '-V\n'" printf -- -V\\n and it will work anywhere - our printf is specially hacked as once upon a time it took no options, and this kind of thing would work. Format strings starting with a '-' don't work in general however, the '--' should be included if the format might begin with a '-'. Even better would be printf -- %s\\n -V (where the -- is optional here). kre aside: I'd use '-V\n' inside "" as well. But as a sh -c command string I'd use: sh -c 'printf -- -V\\n'
Re: CVS commit: src/bin/echo
On Tue, May 14, 2024 at 01:32:25 +, David H. Gutteridge wrote: > Log Message: > echo.1: borrow advice about printf(1) from the OpenBSD man page Unfortunately that advice is not true without further caveats. netbsd$ sh -c "printf '-V\n'" -V $ busybox sh -c "printf '-V\n'" -V ubuntu$ $ dash -c "printf '-V\n'" dash: 1: printf: Illegal option -V $ bash -c "printf '-V\n'" bash: line 1: printf: -V: invalid option printf: usage: printf [-v var] format [arguments] -uwe
lint's strict bool mode (was: Re: CVS commit: src/usr.sbin/flashctl)
Am 13.05.2024 um 16:06 schrieb Taylor R Campbell:
>> Module Name:src
>> Committed By: rillig
>> Date: Sun May 12 19:03:55 UTC 2024
>>
>> Modified Files:
>> src/usr.sbin/flashctl: flashctl.c
>>
>> Log Message:
>> flashctl: fix lint's strict bool mode with Clang preprocessor
>>
>> Treating the return value from the character classification
>> functions as an 'int' is neither elegant nor idiomatic, but it works for
>> now.
>>
>> - if (!isxdigit((unsigned char)str[2]))
>> + if (isxdigit((unsigned char)str[2]) == 0)
>
> Why is this change necessary? Weren't you teaching lint to handle
> this case without complaining?
Yes, I did. The thing is that I only ever tested lint's strict bool mode
with the GCC preprocessor, and that preprocessor marks every token from
a macro expansion as coming from a system header or coming from the
user's code. Therefore, lint could be more lenient when checking the
result of the isxdigit macro, as its main operator, the cast to '(int)',
is from a system header, so it's OK that it has the "wrong" type.
On the other hand, the strcmp function is not listed in "namespace.h"
and does not have a macro definition, and although the function
declaration comes from a system header, the GCC preprocessor does not
mark the function call expression as coming from a system header.
This is the difference by which lint treats 'isxdigit(ch)' as bool-like
but 'strcmp(s1, s2)' as strictly 'int'.
A few days or weeks ago, Christos started builds that have both
MKLLVM=yes and MKLINT=yes, thus using the Clang preprocessor as lint's
preprocessor. Apparently nobody else has done this in the last few
years. Clang's preprocessor's output does not mark the tokens from macro
expansions as coming from a system header or from the user's code. Due
to this, lint can no longer be lenient for system header macro
expansions as it doesn't get the system header information anymore.
> We shouldn't change anything like
>
> if (!isxdigit(...))
> if (ferror(...))
>
> to
>
> if (isxdigit(...) == 0)
> if (ferror(...) != 0)
>
> The original is clearer and idiomatic code, even if it's a little
> silly that the return value is declared as int and not bool
> (presumably for historical reasons, if the interfaces were defined
> before bool existed).
I agree. For usr.bin/error, I tried a different variant, namely to only
activate lint's strict bool mode when MKLLVM is undefined, thus when the
GCC preprocessor is used. I guess activating the strict bool mode only
in GCC mode is good enough to catch all type mismatches.
The combination of MKLLVM=yes MKLINT=yes is also the cause why lint now
allows do-while-0 even in strict bool mode, as the FD_ZERO macro uses
that idiom and I didn't dare to change the macro to do-while-false, as
that would either require , or to deviate from the idiom
by using 'do { ... } while (0 != 0)', as that would look suspicious.
I will switch usr.sbin/flashctl to the only-in-GCC-mode variant and
restore the previous idiomatic code.
Roland
Re: CVS commit: src/usr.sbin/flashctl
> Module Name:src > Committed By: rillig > Date: Sun May 12 19:03:55 UTC 2024 > > Modified Files: > src/usr.sbin/flashctl: flashctl.c > > Log Message: > flashctl: fix lint's strict bool mode with Clang preprocessor > > Treating the return value from the character classification > functions as an 'int' is neither elegant nor idiomatic, but it works for > now. > > - if (!isxdigit((unsigned char)str[2])) > + if (isxdigit((unsigned char)str[2]) == 0) Why is this change necessary? Weren't you teaching lint to handle this case without complaining? We shouldn't change anything like if (!isxdigit(...)) if (ferror(...)) to if (isxdigit(...) == 0) if (ferror(...) != 0) The original is clearer and idiomatic code, even if it's a little silly that the return value is declared as int and not bool (presumably for historical reasons, if the interfaces were defined before bool existed).
Re: CVS commit: src/distrib/common
Date:Thu, 9 May 2024 17:44:16 -0400 From:Christos Zoulas Message-ID: <9c618434-9d7b-4f1c-97ed-3260b7f36...@zoulas.com> | I am not sure either but the resulting cd does not boot anymore. Which version? It has been a long time since I needed to boot from an optical drive, but I could try it. Its a little hard to believe that the uid/gid settings could make any difference, though the m9de settings might. kre
Re: CVS commit: src/distrib/common
> On May 9, 2024, at 5:37 PM, Robert Elz wrote: > > Date:Thu, 9 May 2024 12:09:03 -0400 >From:"Christos Zoulas" >Message-ID: <20240509160903.6e41bf...@cvs.netbsd.org> > > | Instead of augmenting the platform spec with an autogenerated one, > | we should understand why we have missing entries in the first place. > > Is it really important? Everything was fine without it previously, > except that reproducible builds, weren't (as local info was being > used in the CD images). > > As long as the "augmenting" is just providing info for files that > weren't otherwise specified (an issue I admit to not checking in the > change I made) - that is, as long as makefs takes the first entry in > the spec file it is given, should there be more than one for a file > (if it prefers to use the last, then that would just change the order > in which the augmentation file is included, no need to change makefs) > then I'm not really sure what the problem is. I am not sure either but the resulting cd does not boot anymore. I am trying to understand why. If augmenting works as you describe, there is more problem... christos > > That is, I don't see we need to add yet another manual maintenance step > that we need to make in order to add or remove a file from a CD image > (or whatever the image is destined for) when the information being added > isn't really important - but just needs to be consistent. > > kre
Re: CVS commit: src/distrib/common
Date:Thu, 9 May 2024 12:09:03 -0400 From:"Christos Zoulas" Message-ID: <20240509160903.6e41bf...@cvs.netbsd.org> | Instead of augmenting the platform spec with an autogenerated one, | we should understand why we have missing entries in the first place. Is it really important? Everything was fine without it previously, except that reproducible builds, weren't (as local info was being used in the CD images). As long as the "augmenting" is just providing info for files that weren't otherwise specified (an issue I admit to not checking in the change I made) - that is, as long as makefs takes the first entry in the spec file it is given, should there be more than one for a file (if it prefers to use the last, then that would just change the order in which the augmentation file is included, no need to change makefs) then I'm not really sure what the problem is. That is, I don't see we need to add yet another manual maintenance step that we need to make in order to add or remove a file from a CD image (or whatever the image is destined for) when the information being added isn't really important - but just needs to be consistent. kre
re: CVS commit: src/external/mit/xorg/lib
"Taylor R Campbell" writes: > Module Name: src > Committed By: riastradh > Date: Sun May 5 15:25:31 UTC 2024 > > Modified Files: > src/external/mit/xorg/lib/dri: Makefile > src/external/mit/xorg/lib/dri.old: Makefile > > Log Message: > mesa: Build with -Wno-error=typedef-redefinition. > > While here, use CWARNFLAGS.clang instead of an explicit conditional. > > In file included from 110_blorp_exec.c:33: > In file included from > /home/source/ab/HEAD-llvm/xsrc/external/mit/MesaLib/dist/src/intel/blorp/blorp_genX_exec.h:27: > In file included from > /home/source/ab/HEAD-llvm/xsrc/external/mit/MesaLib/dist/src/intel/blorp/blorp_priv.h:30: > /home/source/ab/HEAD-llvm/xsrc/external/mit/MesaLib/dist/src/compiler/nir/nir.h:3840:3: > error: redefinition of typedef 'nir_shader' is a C11 feature [-Werror > ,-Wtypedef-redefinition] > } nir_shader; > ^ > /home/source/ab/HEAD-llvm/xsrc/external/mit/MesaLib/dist/src/intel/compiler/brw_compiler.h:41:27: > note: previous definition is here > typedef struct nir_shader nir_shader; actually, this really is a valid warning and the real fix is to not compile this with -std=gnu99 (or is it gnu+99), but use the default for some and maybe gnu++17 for some parts, going on what the real build for this does. not sure why you changed dri.old/Makefile. it wasn't a problem. i was testing the real fix and i'll revert these when it's in. .mrg.
Re: Clang vs. lint's strict bool mode (was: Re: CVS commit: src/usr.bin/base64)
> On May 3, 2024, at 11:11 AM, Roland Illig wrote: > > Am 02.05.2024 um 22:44 schrieb Christos Zoulas: >> On 2024-05-02 3:04 pm, Christos Zoulas wrote: >>> This is with clang. >>> >> And I don't get it. Gcc produces: >> >> if (ignore && >> # 139 "base64.c" 3 4 >>((int)((_ctype_tab_ + 1)[( >> # 139 "base64.c" >>c >> # 139 "base64.c" 3 4 >>)] & 0x0040)) >> # 139 "base64.c" >> ) >>continue; > > Since the '&&' in the condition comes from a system header, lint is not > as strict as it could be, to allow user code to pass strict bool mode > even when the system headers don't comply. > >> Clang produces: >> if (ignore && ((int)((_ctype_tab_ + 1)[(c)] & 0x0040))) >>continue; > > Clang doesn't distinguish the system parts from the non-system parts, > and that's the crucial difference. I never tested the combination of > Clang with lint. I will do so now. Got it, thank you! christos
Clang vs. lint's strict bool mode (was: Re: CVS commit: src/usr.bin/base64)
Am 02.05.2024 um 22:44 schrieb Christos Zoulas: > On 2024-05-02 3:04 pm, Christos Zoulas wrote: >> This is with clang. >> > And I don't get it. Gcc produces: > >if (ignore && > # 139 "base64.c" 3 4 > ((int)((_ctype_tab_ + 1)[( > # 139 "base64.c" > c > # 139 "base64.c" 3 4 > )] & 0x0040)) > # 139 "base64.c" > ) > continue; Since the '&&' in the condition comes from a system header, lint is not as strict as it could be, to allow user code to pass strict bool mode even when the system headers don't comply. > Clang produces: >if (ignore && ((int)((_ctype_tab_ + 1)[(c)] & 0x0040))) > continue; Clang doesn't distinguish the system parts from the non-system parts, and that's the crucial difference. I never tested the combination of Clang with lint. I will do so now. Roland
Re: CVS commit: src/usr.bin/base64
On 2024-05-02 3:04 pm, Christos Zoulas wrote: On 2024-05-02 2:47 pm, Roland Illig wrote: Am 02.05.2024 um 17:45 schrieb Christos Zoulas: Module Name:src Committed By: christos Date: Thu May 2 15:45:36 UTC 2024 Modified Files: src/usr.bin/base64: Makefile Log Message: comment out strict boolean lint check because isspace() returns int and lint complains. In which exact environment did you experience this? Lint's strict bool mode accepts 'a & b' as having either integer or boolean type, so the macro version of isspace should definitely work. The function variant of isspace doesn't work, though. So maybe you are running outside _NETBSD_SOURCE mode or you have defined _CTYPE_NOINLINE. Any idea how lint can accept isspace as returning int/bool while not assuming int/bool for strcmp? One idea is to explicitly list the "bool-like" functions from the C standard library internally in lint, another more flexible approach is to have a function attribute __declared_int_but_actually_bool. This is with clang. And I don't get it. Gcc produces: if (ignore && # 139 "base64.c" 3 4 ((int)((_ctype_tab_ + 1)[( # 139 "base64.c" c # 139 "base64.c" 3 4 )] & 0x0040)) # 139 "base64.c" ) continue; Clang produces: if (ignore && ((int)((_ctype_tab_ + 1)[(c)] & 0x0040))) continue; and lint complains... christos
Re: CVS commit: src/tests/lib/libm
> Date: Thu, 2 May 2024 21:04:38 +0200 > From: Roland Illig > > Am 02.05.2024 um 05:30 schrieb Robert Elz: > > Use intmax_t instead of long int when trying to represent very large > > integers (10^50 or so), so we don't exceed the capacity of systems where > > long int is only 32 bits. > > I particularly avoid the types 'long' and 'long double', as they vary > between the platforms. In this case, the whole point of the exercise is to test a long double function nearbyintl distinctly from the double function nearbyint. The integer result could have been int64_t instead of intmax_t (and maybe it should be). I wrote it as long mainly because I copied the nearbyint tests to make the nearbyintl tests and just forgot to update the long to make it work on LP32 platforms -- I tested on amd64 before committing and I was thinking about how sparc64/aarch64 must have broken nearbyintl (which the test has now confirmed they are). > Curiously, intmax_t is a 64-bit type even on amd64, where __int128_t is > also available, but I don't use that because that type is not predefined. Yes, although intmax_t looks convenient for arithmetic, it was a mistake to bake it into any ABI like printf "%jd", because it means expanding intmax_t from 64-bit to 128-bit breaks the ABI. Had the rule been to use PRIdMAX instead of "%jd" in the C standard, and had all intmax_t-related functions been defined as macros or static inlines, this problem could have been avoided. But it's too late for that now, so intmax_t is effectively just a confusingly-named alias for int64_t in practice.
Re: CVS commit: src/usr.bin/base64
On 2024-05-02 2:47 pm, Roland Illig wrote: Am 02.05.2024 um 17:45 schrieb Christos Zoulas: Module Name:src Committed By: christos Date: Thu May 2 15:45:36 UTC 2024 Modified Files: src/usr.bin/base64: Makefile Log Message: comment out strict boolean lint check because isspace() returns int and lint complains. In which exact environment did you experience this? Lint's strict bool mode accepts 'a & b' as having either integer or boolean type, so the macro version of isspace should definitely work. The function variant of isspace doesn't work, though. So maybe you are running outside _NETBSD_SOURCE mode or you have defined _CTYPE_NOINLINE. Any idea how lint can accept isspace as returning int/bool while not assuming int/bool for strcmp? One idea is to explicitly list the "bool-like" functions from the C standard library internally in lint, another more flexible approach is to have a function attribute __declared_int_but_actually_bool. This is with clang. christos
Re: CVS commit: src/tests/lib/libm
Am 02.05.2024 um 05:30 schrieb Robert Elz: > Module Name: src > Committed By: kre > Date: Thu May 2 03:30:07 UTC 2024 > > Modified Files: > src/tests/lib/libm: t_fe_round.c > > Log Message: > Use intmax_t instead of long int when trying to represent very large > integers (10^50 or so), so we don't exceed the capacity of systems where > long int is only 32 bits. In the lint tests (which don't have a C preprocessor available), I use the following typedefs to get fixed-width integer types: typedef signed char int8_t; typedef short int16_t; typedef int int32_t; typedef long long int64_t; These types are the same on all platforms supported by lint, and I guess by NetBSD as a whole. I particularly avoid the types 'long' and 'long double', as they vary between the platforms. Curiously, intmax_t is a 64-bit type even on amd64, where __int128_t is also available, but I don't use that because that type is not predefined. Roland
Re: CVS commit: src/usr.bin/base64
Am 02.05.2024 um 17:45 schrieb Christos Zoulas: > Module Name: src > Committed By: christos > Date: Thu May 2 15:45:36 UTC 2024 > > Modified Files: > src/usr.bin/base64: Makefile > > Log Message: > comment out strict boolean lint check because isspace() returns int and lint > complains. In which exact environment did you experience this? Lint's strict bool mode accepts 'a & b' as having either integer or boolean type, so the macro version of isspace should definitely work. The function variant of isspace doesn't work, though. So maybe you are running outside _NETBSD_SOURCE mode or you have defined _CTYPE_NOINLINE. Any idea how lint can accept isspace as returning int/bool while not assuming int/bool for strcmp? One idea is to explicitly list the "bool-like" functions from the C standard library internally in lint, another more flexible approach is to have a function attribute __declared_int_but_actually_bool. Roland
Re: CVS commit: src/tests/lib/libm
And yes, I know, it should have been 2^50 not 10^50... kre
Re: CVS commit: src/lib/libutil
Date:Wed, 1 May 2024 22:27:02 +0200 From:Roland Illig Message-ID: <754bd755-be0a-4eff-aa7b-d53fce9b4...@gmx.de> | > Log Message: | > next should increement by 1 not 2. | | Are you sure? I agree, that change should be reverted. "next" is even documented to be two ... 6 Despite what is stated above, ?next? is actually 2. The input ?next January?, instead of producing a timestamp for January of the following year, produces one for January 2nd, of the current year. Use caution with ?next? it rarely does what humans expect. For example, on a Sunday ?next sunday? means the following Sunday (7 days hence) whereas ?next monday? means the monday that follows that (8 days hence) rather than ?tomorrow? or just ?Mon? (without the ?next?) which is the nearest subsequent Monday. and is actually more useful that way. It is peculiar, but that's how it has worked ~forever. There are limits to how sane a half hearted (but still useful) attempt to understand English idiom can possibly work, we really don't want to attempt to turn parsedate into an AI machine. kre
Re: CVS commit: src/lib/libutil
Am 01.05.2024 um 21:59 schrieb Christos Zoulas: > Module Name: src > Committed By: christos > Date: Wed May 1 19:59:08 UTC 2024 > > Modified Files: > src/lib/libutil: parsedate.y > > Log Message: > next should increement by 1 not 2. Are you sure? I get these test results: > t_parsedate (2/5): 7 test cases > atsecs: [0.006548s] Passed. > dates: [0.007241s] Passed. > dsttimes: [0.007517s] Passed. > gibberish: [0.007637s] Passed. > relative: [0.287375s] Failed: 2258 checks failed; see output for more > details > times: [0.008402s] Passed. > zones: [0.007586s] Passed. After your change, "next sunday" goes backward in time, for example: > From 28110552 (Sun Nov 22 08:29:12 1970) using "next sunday", > obtained 2808 (Sun Nov 22 00:00:00 1970); > expected 28684800 (Sun Nov 29 00:00:00 1970)
Re: CVS commit: src/sys/arch/hp300/dev
Am 30.04.2024 um 11:55 schrieb Izumi Tsutsui:
> Module Name: src
> Committed By: tsutsui
> Date: Tue Apr 30 09:55:46 UTC 2024
>
> Modified Files:
> src/sys/arch/hp300/dev: dma.c
>
> Log Message:
> Fix another fatal typo that prevents dma(4) interrupts.
The buggy code was:
> if ((sc->sc_ipl == ipl) == 0) {
The typo in the first '==' can be found by treating bool as a data type
incompatible with any other scalar type, and this is what lint does in
its "strict bool mode".
Lint is not yet ready for the whole kernel source, as it errors out on
232 of the 3223 source files. But it can check hp300/dma.c, and running
it with the extra flag -T finds the bug, among several false positives.
If you want to play around a bit, the attached patch allows you to
suppress the uninteresting lint warnings in the kernel source, and to
configure per-file lint flags. To detect the above bug in dma.c 1.47, run:
cd OBJDIR/sys/arch/hp300/compile/GENERIC
make dma.ln KERNLINTFLAGS.dma.c=-T
Roland
Index: sys/conf/lint.mk
===
RCS file: /cvsroot/src/sys/conf/lint.mk,v
retrieving revision 1.5
diff -u -r1.5 lint.mk
--- sys/conf/lint.mk27 Aug 2022 21:49:33 - 1.5
+++ sys/conf/lint.mk30 Apr 2024 22:50:59 -
@@ -5,11 +5,25 @@
##
.if !target(lint)
+DEFKERNLINTFLAGS= -bceghnxzFS
+DEFKERNLINTFLAGS+= -X 0# empty declaration
+DEFKERNLINTFLAGS+= -X 2# empty declaration
+DEFKERNLINTFLAGS+= -X 56 # integral constant too large
+DEFKERNLINTFLAGS+= -X 129 # expression with null effect
+DEFKERNLINTFLAGS+= -X 161 # constant in conditional context
+DEFKERNLINTFLAGS+= -X 226 # static variable unused
+DEFKERNLINTFLAGS+= -X 231 # unused parameter
+DEFKERNLINTFLAGS+= -X 236 # unused static function
+DEFKERNLINTFLAGS+= -X 247 # pointer cast may be troublesome
+DEFKERNLINTFLAGS+= -X 309 # lossy bitwise '&'
+DEFKERNLINTFLAGS+= -X 351 # missing header declaration
+DEFKERNLINTFLAGS+= -X 352 # nested 'extern' declaration
+
.PATH: $S
ALLSFILES?=${MD_SFILES} ${SFILES}
LINTSTUBS?=${ALLSFILES:T:R:%=LintStub_%.c}
-KERNLINTFLAGS?=-bceghnxzFS
-NORMAL_LN?=${LINT} ${KERNLINTFLAGS} ${CPPFLAGS:M-[IDU]*} -o $@ -i $<
+KERNLINTFLAGS?=${DEFKERNLINTFLAGS}
+NORMAL_LN?=${LINT} ${KERNLINTFLAGS} ${KERNLINTFLAGS.${.IMPSRC:T}}
${CPPFLAGS:M-[IDU]*} -o $@ -i $<
_lsrc= ${CFILES} ${LINTSTUBS} ${MI_CFILES} ${MD_CFILES}
LOBJS?=${_lsrc:T:.c=.ln} ${LIBKERNLN} ${SYSLIBCOMPATLN}
Re: CVS commit: src/sys/dev/acpi
> Module Name:src > Committed By: christos > Date: Fri Apr 26 18:19:18 UTC 2024 > > Modified Files: > src/sys/dev/acpi: acpi_bat.c > > Log Message: > PR/58201: Malte Dehling: re-order sysmon initialization before acpi > registration, to avoid needing to call to acpi_deregister_notify on sysmon > failure. This isn't really a bug: the detach function calls acpi_deregister_notify. Now, with this change, it will call acpi_deregister_notify even if acpi_register_notify was never called. Fortunately, that's mostly harmless in the current implementation -- just as it was harmless to leave the notifier there; it doesn't use any memory that would be leaked. (Really, if there's any bug here, it's that sysmon_envsys_register can fail at all. This creates vast swaths of never-tested error branches that waste maintainer and auditor time.)
Re: CVS commit: src/external/bsd/ntp/lib/libntp
On Fri, Apr 19, 2024 at 10:48:10PM +0700, Robert Elz wrote:
> Date:Fri, 19 Apr 2024 14:58:18 +
> From:"Jonathan A. Kollasch"
> Message-ID: <20240419145818.351d2f...@cvs.netbsd.org>
>
> | - bail out if resulting __DATE__/__TIME__ replacement strings are empty
>
> If you want to do that (not that it would be useful, even if the %b
> (etc) conversions produced nothing, there would still be two spaces
> in the output. It is almost impossible to get date to exit with an
> error code (and nothing on stdout) in cases like this.
>
> But if this is worth keeping, then
>
> if ${MKREPRO_TIME} == "" || ${MKREPRO_TIME} == ""
>
> probably is not what you wanted.
I've tested this with MKREPRO_TIMESTAMP=RandomNonNumericString, and
MKREPRO_TIME/MKREPRO_DATE came out "" when nbdate produced a non-zero
exit status and a warning message.
I wish nbmake could actually error when it gets a non-zero exit status
there, but it merely spouts a warning and continues.
I've spent enough time looking at this.
Re: CVS commit: src/external/bsd/ntp/lib/libntp
Date:Fri, 19 Apr 2024 14:58:18 +
From:"Jonathan A. Kollasch"
Message-ID: <20240419145818.351d2f...@cvs.netbsd.org>
| - bail out if resulting __DATE__/__TIME__ replacement strings are empty
If you want to do that (not that it would be useful, even if the %b
(etc) conversions produced nothing, there would still be two spaces
in the output. It is almost impossible to get date to exit with an
error code (and nothing on stdout) in cases like this.
But if this is worth keeping, then
if ${MKREPRO_TIME} == "" || ${MKREPRO_TIME} == ""
probably is not what you wanted.
kre
Re: CVS commit: src/external/bsd/ntp/lib/libntp
On Fri 19 Apr 2024 at 14:47:23 +0200, Martin Husemann wrote: > The problem (IIUC) is that the ntp code parses this value internally, so > it won't talk to anyone claiming a time before the time ntpd was compiled > (or something along that line). Would it make sense to just supply a fixed string to effectively defang that code? Or just rip it out completely. It sounds like a giant footgun somehow. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: CVS commit: src/external/bsd/ntp/lib/libntp
Date:Fri, 19 Apr 2024 14:57:46 +0200 From:Martin Husemann Message-ID: <20240419125746.gb26...@mail.duskware.de> | On Fri, Apr 19, 2024 at 02:47:23PM +0200, Martin Husemann wrote: | > The commit message could have explained that a bit. | | And it actually should have been "+%b %e %Y" - from the C18 standard draft: | | 6.10.8.1 Mandatory macros | | __DATE__ | | The date of translation of the preprocessing translation unit: a | character string literal of the form "Mmm dd ", where the names of | the months are the same as those generated by the asctime function, If that's still in the most recent C (in that form anyway) I'd be surprised, as asctime() is more or less deprecated I think. But if that is what is required, then the TOOL_DATE needs to be run with LC_ALL=C (or LC_ALL=POSIX) so that you get the month name in English, rather than whatever the local locale's short name for the month would be. It is still a stupid format... kre
Re: CVS commit: src/external/bsd/ntp/lib/libntp
On Fri, Apr 19, 2024 at 02:47:23PM +0200, Martin Husemann wrote: > The commit message could have explained that a bit. And it actually should have been "+%b %e %Y" - from the C18 standard draft: 6.10.8.1 Mandatory macros __DATE__ The date of translation of the preprocessing translation unit: a character string literal of the form "Mmm dd ", where the names of the months are the same as those generated by the asctime function, and the first character of dd is a space character if the value is less than 10. If the date of translation is not available, an implementation-defined valid date shall be supplied. Martin
Re: CVS commit: src/external/bsd/ntp/lib/libntp
On Fri, Apr 19, 2024 at 04:36:46PM +0700, Robert Elz wrote:
> I don't understand that change, it altered from
>
> MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%F"
> to
> MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%b %d %Y"
>
> %F is simply a shorthand for %Y-%m-%d (which is the correct way to write
> locale independent dates), %b is a locale dependent name of the month, and
> what's more this is in US-centric mon day year format, which we should avoid
> (aside from anything else, it is a dumb format, with the smallest value unit
> sitting in the middle, rather than at one end or the other).
The problem (IIUC) is that the ntp code parses this value internally, so
it won't talk to anyone claiming a time before the time ntpd was compiled
(or something along that line).
And __DATE__ gives us a stupid format:
> echo __DATE__ | cc -E - | tail -1
"Apr 19 2024"
which is different from
> date -u -r 1713530399 "+%F"
2024-04-19
but matches
> date -u -r 1713530399 "+%b %d %Y"
Apr 19 2024
The commit message could have explained that a bit.
Martin
Re: CVS commit: src/external/bsd/ntp/lib/libntp
Date:Thu, 18 Apr 2024 19:23:54 +
From:"Jonathan A. Kollasch"
Message-ID: <20240418192354.1bcc1f...@cvs.netbsd.org>
| Module Name:src
| Committed By: jakllsch
| Date: Thu Apr 18 19:23:54 UTC 2024
|
| Modified Files:
| src/external/bsd/ntp/lib/libntp: Makefile
|
| Log Message:
| Format MKREPRO_TIMESTAMP with "%b %d %Y" to correctly substitute __DATE__
I don't understand that change, it altered from
MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%F"
to
MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%b %d %Y"
%F is simply a shorthand for %Y-%m-%d (which is the correct way to write
locale independent dates), %b is a locale dependent name of the month, and
what's more this is in US-centric mon day year format, which we should avoid
(aside from anything else, it is a dumb format, with the smallest value unit
sitting in the middle, rather than at one end or the other).
If there is a problem where support for %F is missing somewhere, (and if
that happens in TOOL_DATE it must mean that we're using a locale strftime()
when building it, in which case we should add our version to the library)
please replace it with %Y-%m-%d (which is what it is defined to be) instead
of anything using %b (or %a or %B or %A) (or any other weird formats).
Further, if some format like that was needed for some reason, then it
probably should use %e rather than %d (to suppress the leading 0 on dates
before the 10th). But don't just do that either.
If there isn't an actual problem using %F, please just revert this.
And lastly, and this applies to everyone - please do not request
pullups of anything (except perhaps urgent security fixes) immediately
after the change is committed - give it at least a few days, in case of
objection, breakage, ...
kre
Re: CVS commit: src/distrib/amd64/liveimage/emuimage
maya@ wrote:
> Module Name: src
> Committed By: maya
> Date: Tue Apr 16 16:13:45 UTC 2024
>
> Modified Files:
> src/distrib/amd64/liveimage/emuimage: Makefile rc.conf.emuimage
> spec.emuimage
>
> Log Message:
> restore amd64 live image support for resize root after combined mbr/gpt commit
>
> we need to resize_gpt now, as it takes precedence over mbr/disklabel
> this change brings us to behave like the evbarm images.
>
> XXX: we don't seem to touch disklabel and MBR, but they exist. Not sure
> whether
> that has any negative repercussions, maybe another system might regard MBR as
> the
> sole source of truth when GPT also exists.
Actually disklabel or MBR does NOT exist in USE_GPT=YES case.
In src/distrib/common/bootimage/Makefile.bootimage,
both ${TOOL_FDISK} and ${TOOL_DISKLABEL} are only invoked
inside .if ${USE_GPT} == "no".
"${TOOL_GPT} biosboot -c /usr/mdec/gptmbr.bin" by USE_GPTMBR=yes
does all the tricks, i.e. gptmbr.bin in the MBR sector just reads
the first sector of the specified GPT partition:
https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/mbr/gptmbr.S
and the loaded pbr.S in the primary bootxx checks a GPT partition table
and loads the whole (~8KB) the primary bootxx:
https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/bootxx/pbr.S#L134-L135
https://github.com/NetBSD/src/blob/124fe5e/sys/arch/i386/stand/bootxx/pbr.S#L372-L380
Maybe this is the reason why some odd machines cannot boot UEFI images
(such ugly implemantations might assume MBR partition really exists).
---
Izumi Tsutsui
mtree [was Re: CVS commit: src]
> And also slightly related: we need a way to mark directories as > optional in the mtree files (or have a way to provide several > alternative options). Typical issue: /var/shm is a symlink on most > of my smaller machines, but it is impossible to make such setups pass > the mtree tests. Maybe a way to mark an entry as, effectively, "use stat() instead of lstat() when checking this entry"? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: CVS commit: src
On Thu, Apr 11, 2024 at 01:06:10PM +, Taylor R Campbell wrote: > I agree, this is related to the subject of, and could probably use the > same mechanism as, PR 57581: set lists should have a way to obsolete > shlibs in DESTDIR but not in postinstall. > > https://gnats.NetBSD.org/57581 And also slightly related: we need a way to mark directories as optional in the mtree files (or have a way to provide several alternative options). Typical issue: /var/shm is a symlink on most of my smaller machines, but it is impossible to make such setups pass the mtree tests. Martin
Re: CVS commit: src
> Date: Thu, 11 Apr 2024 11:19:38 +0700 > From: Robert Elz > > This is why I'd like to add a new keyword in the sets lists, like > "obsolete" is - probably "optional" to mark files that aren't installed > by the build, but might exist, and should simply be ignored if > found - it isn't an error for them to exist, but nor is it an error > for them to be absent. Such files don't go in any of the constructed > sets files (whether they happen to exist or not). I agree, this is related to the subject of, and could probably use the same mechanism as, PR 57581: set lists should have a way to obsolete shlibs in DESTDIR but not in postinstall. https://gnats.NetBSD.org/57581
Re: CVS commit: src
Hi, Periodic snapshot build fails for (probably) all platforms with MKCOMPAT enabled: http://releng.netbsd.org/builds/HEAD/202404101150Z/ Please take a look. And more importantly, careful tests are always appreciated before commit. To be fair, there are tons of combinations of mk.conf variables, although ;) Thanks, rin On 2024/04/10 0:17, Nia Alarie wrote: Module Name:src Committed By: nia Date: Tue Apr 9 15:17:25 UTC 2024 Modified Files: src/distrib/common/bootimage: Makefile.bootimage src/distrib/sets: maketars regpkgset sets.subr src/distrib/sets/lists/base: ad.aarch64 ad.arm ad.mips ad.powerpc md.amd64 md.sparc64 mi shl.mi src/distrib/sets/lists/debug: ad.aarch64 md.amd64 md.sparc64 mi shl.mi src/distrib/sets/lists/etc: mi src/distrib/sets/lists/man: mi src/distrib/utils/embedded: mkimage src/usr.sbin/sysinst: Makefile.inc defs.h msg.mi.de msg.mi.en msg.mi.es msg.mi.fr msg.mi.pl util.c src/usr.sbin/sysinst/arch/amd64: md.h src/usr.sbin/sysinst/arch/evbarm: md.h Added Files: src/distrib/sets/lists/base32: ad.aarch64 ad.mips64eb ad.mips64el ad.mipsn64eb ad.mipsn64el ad.powerpc64 ad.riscv64 md.amd64 md.sparc64 mi src/distrib/sets/lists/debug32: ad.aarch64 ad.mips64eb ad.mips64el ad.mipsn64eb ad.mipsn64el ad.powerpc64 ad.riscv64 md.amd64 md.sparc64 mi src/distrib/sets/lists/manhtml: mi Log Message: Add new sets: base32, debug32, manhtml - base32 contains (when MKCOMPAT=yes) shared libraries for 32-bit compatibility, previously included in base - debug32 contains (when MKCOMPAT=yes) debug symbols and static libraries containing debug symbols for 32-bit compatiblity, previously included in debug - manhtml contains (when MKHTML=yes) the HTML files previously included in 'man', which are of limited utility without third-party software. The motivation for this change is to be able to easily exclude sets from CD-ROM images that go over the size limit without xz compression (which many NetBSD platforms struggle to extract at acceptable speeds). To generate a diff of this commit: cvs rdiff -u -r1.33 -r1.34 src/distrib/common/bootimage/Makefile.bootimage cvs rdiff -u -r1.100 -r1.101 src/distrib/sets/maketars cvs rdiff -u -r1.17 -r1.18 src/distrib/sets/regpkgset cvs rdiff -u -r1.204 -r1.205 src/distrib/sets/sets.subr cvs rdiff -u -r1.45 -r1.46 src/distrib/sets/lists/base/ad.aarch64 cvs rdiff -u -r1.87 -r1.88 src/distrib/sets/lists/base/ad.arm cvs rdiff -u -r1.93 -r1.94 src/distrib/sets/lists/base/ad.mips cvs rdiff -u -r1.47 -r1.48 src/distrib/sets/lists/base/ad.powerpc cvs rdiff -u -r1.296 -r1.297 src/distrib/sets/lists/base/md.amd64 cvs rdiff -u -r1.262 -r1.263 src/distrib/sets/lists/base/md.sparc64 cvs rdiff -u -r1.1341 -r1.1342 src/distrib/sets/lists/base/mi cvs rdiff -u -r1.978 -r1.979 src/distrib/sets/lists/base/shl.mi cvs rdiff -u -r0 -r1.1 src/distrib/sets/lists/base32/ad.aarch64 \ src/distrib/sets/lists/base32/ad.mips64eb \ src/distrib/sets/lists/base32/ad.mips64el \ src/distrib/sets/lists/base32/ad.mipsn64eb \ src/distrib/sets/lists/base32/ad.mipsn64el \ src/distrib/sets/lists/base32/ad.powerpc64 \ src/distrib/sets/lists/base32/ad.riscv64 \ src/distrib/sets/lists/base32/md.amd64 \ src/distrib/sets/lists/base32/md.sparc64 src/distrib/sets/lists/base32/mi cvs rdiff -u -r1.37 -r1.38 src/distrib/sets/lists/debug/ad.aarch64 cvs rdiff -u -r1.123 -r1.124 src/distrib/sets/lists/debug/md.amd64 cvs rdiff -u -r1.89 -r1.90 src/distrib/sets/lists/debug/md.sparc64 cvs rdiff -u -r1.430 -r1.431 src/distrib/sets/lists/debug/mi cvs rdiff -u -r1.339 -r1.340 src/distrib/sets/lists/debug/shl.mi cvs rdiff -u -r0 -r1.1 src/distrib/sets/lists/debug32/ad.aarch64 \ src/distrib/sets/lists/debug32/ad.mips64eb \ src/distrib/sets/lists/debug32/ad.mips64el \ src/distrib/sets/lists/debug32/ad.mipsn64eb \ src/distrib/sets/lists/debug32/ad.mipsn64el \ src/distrib/sets/lists/debug32/ad.powerpc64 \ src/distrib/sets/lists/debug32/ad.riscv64 \ src/distrib/sets/lists/debug32/md.amd64 \ src/distrib/sets/lists/debug32/md.sparc64 \ src/distrib/sets/lists/debug32/mi cvs rdiff -u -r1.273 -r1.274 src/distrib/sets/lists/etc/mi cvs rdiff -u -r1.1771 -r1.1772 src/distrib/sets/lists/man/mi cvs rdiff -u -r0 -r1.1 src/distrib/sets/lists/manhtml/mi cvs rdiff -u -r1.81 -r1.82 src/distrib/utils/embedded/mkimage cvs rdiff -u -r1.47 -r1.48 src/usr.sbin/sysinst/Makefile.inc cvs rdiff -u -r1.90 -r1.91 src/usr.sbin/sysinst/defs.h cvs rdiff -u -r1.45 -r1.46 src/usr.sbin/sysinst/msg.mi.de \ src/usr.sbin/sysinst/msg.mi.fr cvs rdiff -u -r1.48 -r1.49 src/usr.sbin/sysinst/msg.mi.en cvs rdiff -u -r1.40 -r1.41 src/usr.sbin/sysinst/msg.mi.es cvs rdiff -u -r1.46 -r1.47 src/usr.sbin/sysinst/msg.mi.pl cvs rdiff -u -r1.74 -r1.75 src/usr.sbin/sysinst/util.c cvs rdiff -u
Re: CVS commit: src
Date:Thu, 11 Apr 2024 02:15:39 + From:"Taylor R Campbell" Message-ID: <20240411021539.a3272f...@cvs.netbsd.org> | However, this means that update builds need manual intervention to | delete $DESTDIR/var/run/named or else checkflist will fail, so add a | note to UPDATING about this. This is why I'd like to add a new keyword in the sets lists, like "obsolete" is - probably "optional" to mark files that aren't installed by the build, but might exist, and should simply be ignored if found - it isn't an error for them to exist, but nor is it an error for them to be absent. Such files don't go in any of the constructed sets files (whether they happen to exist or not). Or since there is no particular set to list them in (as they belong in none) perhaps an additional lists file to contain just these optional files, (to keep the format, they'd still need some keyword, so perhaps still "optional" - but excluding them from being added to all sets .*z files would be automatic, as none would be built from that one. | PR misc/57877 kre
Re: CVS commit: src/lib/libutil
On Mon, Apr 08, 2024 at 23:31:16 +0200, Roland Illig wrote: > Am 08.04.2024 um 21:18 schrieb Valery Ushakov: > > "=\017FIFTEEN\0" > > > > with its result a few lines below that has: > > > > BURST=0xf=FIFTEEN > > Thank you for explaining this example. I had a gut feeling that there > would be some hidden correlation between some octal/hexadecimal > combinations, but I couldn't name it. Indeed, if the number base for > output is hexadecimal, the field comparisons should be done in > hexadecimal as well. > > I adjusted the description and examples in the manual page accordingly. Thanks! My unscientific impression is that snprintb(3) was not very popular and its uses sometimes are a bit of a cargo-cult, so existing use cases have to be taken with a grain of salt and don't necessarily represent good style. This is why improving the docs with good examples is important, imho. -uwe
Re: CVS commit: src/lib/libutil
Am 08.04.2024 um 21:18 schrieb Valery Ushakov: > "=\017FIFTEEN\0" > > with its result a few lines below that has: > > BURST=0xf=FIFTEEN Thank you for explaining this example. I had a gut feeling that there would be some hidden correlation between some octal/hexadecimal combinations, but I couldn't name it. Indeed, if the number base for output is hexadecimal, the field comparisons should be done in hexadecimal as well. I adjusted the description and examples in the manual page accordingly. Roland
Re: CVS commit: src/lib/libutil
On Mon, Apr 08, 2024 at 20:21:07 +0200, Roland Illig wrote: > I didn't eradicate _all_ hexadecimal examples, I just made each example > use only one number base, not mix them both. There are both octal and > hexadecimal examples in the manual page. That's not what "prefer octal in examples" conveys. I would also say that source code that says "=\x0f" "FIFTEEN\0" aligns much better than "=\017FIFTEEN\0" with its result a few lines below that has: BURST=0xf=FIFTEEN -uwe
Re: CVS commit: src/lib/libutil
Am 08.04.2024 um 03:24 schrieb Valery Ushakov: > On Sun, Apr 07, 2024 at 14:28:27 +, Roland Illig wrote: > >> Log Message: >> snprintb.3: clean up formatting and wording, prefer octal in examples >> >> Using hexadecimal character escapes requires separate string literals if >> the description starts with one of the letters A-F; octal character >> escapes have at most 3 digits, reducing ambiguity. > > 70s are over, very few people speak octal fluently. If anything, the > man page should highlight the potential snag. Besides, separate > literal for the name is good for readability anyway. When I looked through the NetBSD tree exploring the current usage, I found that a significant majority uses octal instead of hexadecimal. I don't know the exact reasons for this, it might be due to existing practice in the 1990s, to avoid splitting the bit position and the description to separate string literals, to be able to easily split the bit position into the byte and the bit portion mentally, or maybe something entirely different. While your claim that "very few people speak octal fluently" may be true for programmers in general, I expect those using the snprintb function to be more fluent than others. Of course, I saw cases where "\040" was followed by "\039", just as I saw cases of "\x0fFIELD". Lint now warns in both these cases. Regarding the separate literals, I didn't see them in wide use up to now. Existing code seems to focus more on compressing the source code into as few lines as possible rather than making it easily readable. I agree that separate string literals are more readable, and I converted the example that uses hexadecimal escapes to this style. I didn't eradicate _all_ hexadecimal examples, I just made each example use only one number base, not mix them both. There are both octal and hexadecimal examples in the manual page. Roland
Re: CVS commit: src/sbin/ifconfig
Hi, It's likely minor, but I believe these changes are enough to also update the documentation date: Index: ./src/sbin/ifconfig/ifconfig.8 -.Dd November 25, 2022 +.Dd April 8, 2024 Also "If the interface id a lagg(4) pseudo-interface" probably was meant to be "If the interface is a lagg(4)..." (id->is). Thank you for the changes! Regards, Andrius V On Mon, Apr 8, 2024 at 7:29 AM Shoichi YAMAGUCHI wrote: > > Module Name:src > Committed By: yamaguchi > Date: Mon Apr 8 04:29:52 UTC 2024 > > Modified Files: > src/sbin/ifconfig: ifconfig.8 > > Log Message: > Added documents about parameters related to lagg(4) > > PR misc/58125 > > > To generate a diff of this commit: > cvs rdiff -u -r1.125 -r1.126 src/sbin/ifconfig/ifconfig.8 > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/lib/libutil
On Sun, Apr 07, 2024 at 14:28:27 +, Roland Illig wrote: > Log Message: > snprintb.3: clean up formatting and wording, prefer octal in examples > > Using hexadecimal character escapes requires separate string literals if > the description starts with one of the letters A-F; octal character > escapes have at most 3 digits, reducing ambiguity. 70s are over, very few people speak octal fluently. If anything, the man page should highlight the potential snag. Besides, separate literal for the name is good for readability anyway. Please, revert. -uwe
Re: CVS commit: src/external
In article <20240405085127.b998ef...@cvs.netbsd.org>, Robert Elz wrote: >Module Name: src >Committed By: kre >Date: Fri Apr 5 08:51:27 UTC 2024 > >Modified Files: > src/external: Makefile > src/external/mit/libuv/lib: Makefile > >Log Message: >Probable hack fix for current build breakage. > >Make sure to build external/mit before external/mpl (as bind in mpl >needs libuv from mit) and in mit/libuv make sure to build the >static library with the new MAKESTATICLIB mechanism, as that is >what bind needs. Thanks for fixing. The Makefile in external does not handle dependencies and I don't think it gets invoked until libraries have been built, which in src/lib/Makefile handles the mit/uv mpl/bind order. The change you made is fine, I will make the line shorter. The libuv Makefile change is ok too, but it is simplere to just not build the pic library in the first place, which is what I have done. christos
Re: CVS commit: src/external
Date:Fri, 5 Apr 2024 08:51:27 + From:"Robert Elz" Message-ID: <20240405085127.b998ef...@cvs.netbsd.org> Christos, this seems to fix the builds, but I doubt it is really done correctly (and I don't just mean the overlong line I left in src/external/Makefile which was (temporarily) deliberate just to reduce the diff). kre | Modified Files: | src/external: Makefile | src/external/mit/libuv/lib: Makefile | | Log Message: | Probable hack fix for current build breakage. | | Make sure to build external/mit before external/mpl (as bind in mpl | needs libuv from mit) and in mit/libuv make sure to build the | static library with the new MAKESTATICLIB mechanism, as that is | what bind needs. | | To generate a diff of this commit: | cvs rdiff -u -r1.23 -r1.24 src/external/Makefile | cvs rdiff -u -r1.6 -r1.7 src/external/mit/libuv/lib/Makefile
Re: CVS commit: src
On Sat, Mar 30, 2024 at 23:20:38 -0400, Christos Zoulas wrote: > Restore the minimum build to install elfdefinitions.h. Provide a pre-built > copy, since we don't have m4 available. Use pax to install it because > using the Makefile needs more stuff available (nbsed) which we have not > built yet. I haven't looked, but on the surface that seems weird. m4 hardly needs elftoolchain to build, so why can't we reorder things? -uwe
Re: CVS commit: src/games/larn
On Sun, Mar 24, 2024 at 21:21:39 +0200, Andrius V wrote: > Can you a bit clarify the meaning of "8 space tabs" This is what VT set up screen called "Set 8 Column Tabs", i.e. "set one tab every eight columns, starting at column 9" which was the default setting. https://vt100.net/docs/tp83/chapter4.html#T4-11 https://vt100.net/docs/vt420-uu/chapter5.html#S5.11 Emacs calls this tab-width. vi, I believe calls it tabstop. Both default to 8. I know this is a subject that people are often religious about, but I think it's reasonable to require that when a file is cat(1) to the terminal (say, vt220) or an emulator (say, xterm) in it's default state, it displays as intended. > since file is not exactly following any completely defined pattern. I haven't looked at the rest of the file too closely, but the indented multi-line comments I referred to are definitely meant to be viewed with 8 space tabs and in general the 8 space tabs are the default (see above). If some parts of that file deviate from that they should be fixed, but I was referring specifically to your change that looks like this with the default 8 column tabs (untabified to ensure that it's displayed the same regardless of the viewer's tab settings): * setupvt100() Subroutine to set up terminal in correct mode for game * clearvt100() Subroutine to clean up terminal when the game is over * ttgetch()Routine to read in one character from the terminal * scbr() Function to set cbreak -echo for the terminal * sncbr() Function to set -cbreak echo for the terminal * newgame()Subroutine to save the initial time and seed rnd() That text looks aligned with 4 column tabs (again, the text below is untabified): * setupvt100() Subroutine to set up terminal in correct mode for game * clearvt100() Subroutine to clean up terminal when the game is over * ttgetch()Routine to read in one character from the terminal * scbr() Function to set cbreak -echo for the terminal * sncbr() Function to set -cbreak echo for the terminal * newgame()Subroutine to save the initial time and seed rnd() If you would like to go and fix the rest of the file, that would be nice, but my request was to at least not introduce more non-standart tabs. Thanks! -uwe
Re: CVS commit: src/games/larn
Hi,
Can you a bit clarify the meaning of "8 space tabs", since file is not
exactly following any completely defined pattern. Should I use tabs
before multiline comment text (*^I^I) and align
text between routine name and description, also remove all unnecessary
whitespace characters? Attached reformatted file, can you please
review, if formatting would match the expectations?
On Sun, Mar 24, 2024 at 2:33 AM Valery Ushakov wrote:
>
> On Sat, Mar 23, 2024 at 21:10:45 +, Andrius Varanavicius wrote:
>
> > Modified Files:
> > src/games/larn: io.c
> >
> > Log Message:
> > Attempt to fix descriptions of the routines in the initial comment block.
>
> Please, can you fix this to use 8 space tabs as the rest of the file
> does, as can be verified by multiline comments formatted as
>
> /* ...
> * ... */
>
> -uwe
/* $NetBSD: io.c,v 1.29 2021/05/02 12:50:45 rillig Exp $ */
/*
* io.c Larn is copyrighted 1986 by Noah Morgan.
*
* Below are the functions in this file:
*
* setupvt100() Subroutine to set up terminal in correct mode for game
* clearvt100() Subroutine to clean up terminal when the game is over
* ttgetch() Routine to read in one character from the terminal
* scbr() Function to set cbreak -echo for the terminal
* sncbr() Function to set -cbreak echo for the terminal
* newgame() Subroutine to save the initial time and seed rnd()
*
* FILE OUTPUT ROUTINES
*
* lprintf(format,args . . .) printf to the output buffer
* lprint(integer) send binary integer to output buffer
* lwrite(buf,len) write a buffer to the output buffer
* lprcat(str) append a string to the output buffer
*
* FILE OUTPUT MACROS (in header.h)
*
* lprc(character) put the character into the output buffer
*
* FILE INPUT ROUTINES
*
* long lgetc() read one character from input buffer
* long larn_lrint() read one integer from input buffer
* lrfill(address,number) put input bytes into a buffer char
* *lgetw() get a whitespace ended word from
* input char *lgetl() get a \n or EOF ended line from input
*
* FILE OPEN / CLOSE ROUTINES
*
* lcreat(filename) create a new file for write
* lopen(filename) open a file for read
* lappend(filename) open for append to an existing file
* lrclose() close the input file
* lwclose() close output file
* lflush() flush the output buffer
*
* Other Routines
*
* cursor(x,y) position cursor at [x,y]
* cursors() position cursor at [1,24] (saves memory)
* cl_line(x,y) clear line at [1,y] and leave cursor at [x,y]
* cl_up(x,y) clear screen from [x,1] to current line
* cl_dn(x,y) clear screen from [1,y] to end of display
* standout(str) print the string in standout mode
* set_score_output() called when output should be literally printed
* ttputch(ch) print one character in decoded output buffer
* flush_buf() flush buffer with decoded output
* init_term() terminal initialization -- setup termcap info
* char *tmcapcnv(sd,ss) routine to convert VT100 \33's to termcap format
* beep() routine to emit a beep if enabled
*(see no-beep in .larnopts)
*
* Note: ** entries are available only in termcap mode.
*/
#include
#ifndef lint
__RCSID("$NetBSD: io.c,v 1.29 2021/05/02 12:50:45 rillig Exp $");
#endif /* not lint */
#include "header.h"
#include "extern.h"
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifdef TERMIO
#include
#define sgttyb termio
#define stty(_a,_b) ioctl(_a,TCSETA,_b)
#define gtty(_a,_b) ioctl(_a,TCGETA,_b)
#endif
#ifdef TERMIOS
#include
#define sgttyb termios
#define stty(_a,_b) tcsetattr(_a,TCSADRAIN,_b)
#define gtty(_a,_b) tcgetattr(_a,_b)
#endif
#if defined(TERMIO) || defined(TERMIOS)
static int rawflg = 0;
static char saveeof, saveeol;
#define doraw(_a) \
if(!rawflg) { \
++rawflg; \
saveeof = _a.c_cc[VMIN]; \
saveeol = _a.c_cc[VTIME]; \
} \
_a.c_cc[VMIN] = 1; \
_a.c_cc[VTIME] = 1; \
_a.c_lflag &= ~(ICANON|ECHO|ECHOE|ECHOK|ECHONL)
#define unraw(_a) \
_a.c_cc[VMIN] = saveeof; \
_a.c_cc[VTIME] = saveeol; \
_a.c_lflag |= ICANON|ECHO|ECHOE|ECHOK|ECHONL
#else /* not TERMIO or TERMIOS */
#ifndef BSD
#define CBREAK RAW /* V7 has no CBREAK */
#endif
#define doraw(_a) (_a.sg_flags |= CBREAK,_a.sg_flags &= ~ECHO)
#define unraw(_a) (_a.sg_flags &= ~CBREAK,_a.sg_flags |= ECHO)
#include
#endif /* not TERMIO or TERMIOS */
#ifndef NOVARARGS /* if we have varargs */
#include
#else /* NOVARARGS */ /* if we don't have varargs */
typedef char *va_list;
#define va_dcl int va_alist;
#define va_start(plist) plist = (char *) _alist
#define va_end(plist)
#define va_arg(plist,mode) ((mode *)(plist += sizeof(mode)))[-1]
#endif /* NOVARARGS */
static int ttputch(int ch);
static void flush_buf(void);
#define LINBUFSIZE 128 /* size of the lgetw() and lgetl() buffer */
int io_outfd; /* output file numbers */
int io_infd; /* input file numbers */
static struct sgttyb ttx;/* storage for the tty modes */
static int
Re: CVS commit: src/games/larn
On Sat, Mar 23, 2024 at 21:10:45 +, Andrius Varanavicius wrote: > Modified Files: > src/games/larn: io.c > > Log Message: > Attempt to fix descriptions of the routines in the initial comment block. Please, can you fix this to use 8 space tabs as the rest of the file does, as can be verified by multiline comments formatted as /* ... * ... */ -uwe
Re: CVS commit: src/usr.bin/stat
Am 14.03.2024 um 21:27 schrieb Robert Elz: > Date:Thu, 14 Mar 2024 20:53:13 +0100 > From:Roland Illig > Message-ID: <9c7513f7-97b5-4d3b-9d66-dce483af7...@gmx.de> > > | I don't think the flags '+' and '0' make sense for strings, that's why I > | decided to preserve existing behavior. > > But the change only affected things when the # flag was given. I agree > that + and 0 are meaningless for strings, but - isn't, and %-S would work, > I see no reason why %#-S shouldn't work as well. > > Not exactly a serius problem, as clearly no-one ever seems to have > been bothered by it, but no-one intentionally writes the code as it > was (generating clear everything) - the ! was obviously just a thinko > for ~. I agree. Thank you for fixing the left-aligned output, I wrote a few tests for these cases. Roland
Re: CVS commit: src/usr.bin/stat
Date:Thu, 14 Mar 2024 20:53:13 +0100 From:Roland Illig Message-ID: <9c7513f7-97b5-4d3b-9d66-dce483af7...@gmx.de> | I don't think the flags '+' and '0' make sense for strings, that's why I | decided to preserve existing behavior. But the change only affected things when the # flag was given. I agree that + and 0 are meaningless for strings, but - isn't, and %-S would work, I see no reason why %#-S shouldn't work as well. Not exactly a serius problem, as clearly no-one ever seems to have been bothered by it, but no-one intentionally writes the code as it was (generating clear everything) - the ! was obviously just a thinko for ~. kre
Re: CVS commit: src/usr.bin/stat
Am 14.03.2024 um 20:38 schrieb Robert Elz: > Module Name: src > Committed By: kre > Date: Thu Mar 14 19:38:56 UTC 2024 > > Modified Files: > src/usr.bin/stat: stat.c > > Log Message: > While the change in 1.51 certainly retained binary compat with > what was in 1.50 (while silencing LINT) - it was clearly not the > correct change to make. The code used !FLAG_POUND where it > clearly meant ~FLAG_POUND ... the former is 0, so &= 0 could > be replaced by =0 changing nothing. But that's not what it > should have been doing, other flags should not have been > removed here, just FLAG_POUND. I don't think the flags '+' and '0' make sense for strings, that's why I decided to preserve existing behavior. Roland
Re: CVS commit: src/sys/arch/evbmips/evbmips
Thanks, should take remember this for the future reference. On Wed, Mar 13, 2024 at 8:59 AM Nick Hudson wrote: > > Module Name:src > Committed By: skrll > Date: Wed Mar 13 06:59:01 UTC 2024 > > Modified Files: > src/sys/arch/evbmips/evbmips: interrupt.c > > Log Message: > Remove #ifdef DIAGNOSTIC by using __diagused. NFCI. > > > To generate a diff of this commit: > cvs rdiff -u -r1.26 -r1.27 src/sys/arch/evbmips/evbmips/interrupt.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/tools/gcc
Hi,
"matthew green" writes:
> Module Name: src
> Committed By: mrg
> Date: Thu Feb 22 02:47:27 UTC 2024
>
> Modified Files:
> src/tools/gcc: Makefile
>
> Log Message:
> enable isl support for GCC 12.
I have HAVE_GCC=12 in my /etc/mk.conf.
I have gotten the following error.
Maybe something for isl library is missing in the src tree.
Could you take a look at my problem?
Thank you.
checking for objdir... .libs [463/94127]
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for isl 0.15 or later... no
required isl version is 0.15 or later
configure: error: Unable to find a usable isl. See config.log for details.
*** Failed target: .configure_done
*** Failed commands:
@mkdir build 2>/dev/null || true
@(cd build && ${CONFIGURE_ENV} ${HOST_SH} ${GNUHOSTDIST}/configure ${CON
FIGURE_ARGS})
=> @(cd build && gcc_cv_libc_provides_ssp=yes gcc_cv_as_sparc_gotdata_o
p=no AR=ar AWK=/usr/world/10.99/amd64/tools/bin/nbawk CC=cc CFLAGS=-O CONFIG
_SHELL=/bin/sh CPPFLAGS= CXX=c++ CXXFLAGS=-O INSTALL=/usr/world/10.99/amd64/
tools/bin/x86_64--netbsd-install\ -c\ -p\ -r LDFLAGS= LEX=/usr/world/10.99/amd
64/tools/bin/nblex FLEX=/usr/world/10.99/amd64/tools/bin/nblex M4=/usr/world/1
0.99/amd64/tools/bin/nbm4 MAKE=/usr/world/10.99/amd64/tools/bin/nbgmake PATH="
/usr/world/10.99/amd64/tools/bin:$PATH" RANLIB=ranlib YACC=/usr/world/10.99/am
d64/tools/bin/nbyacc /bin/sh /usr/src/tools/gcc/../../external/gpl3/gcc/dist/con
figure --target=x86_64--netbsd --enable-long-long --enable-threads --with-bug
url=http://www.NetBSD.org/support/send-pr.html --with-pkgversion="NetBSD nb1 20
230729" --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-time=rt
--enable-libstdcxx-threads --with-diagnostics-color=auto-if-env --with-tune=noc
ona --with-default-libstdcxx-abi=new --with-sysroot=/usr/world/10.99/amd64/dest
--with-mpc=/usr/world/10.99/amd64/tools --with-mpfr=/usr/world/10.99/amd64/too
ls --with-gmp=/usr/world/10.99/amd64/tools --with-isl=/usr/world/10.99/amd64/t
ools --disable-nls --enable-multilib--program-transform-name="s,^,x86_64--
netbsd-," --enable-languages="c c++ objc" --prefix=/usr/world/10.99/amd64/tools
)
@echo ${BUILD_PLATFORM} > $@
=> @echo NetBSD-10.99.10-amd64 > .configure_done
*** [.configure_done] Error code 1
nbmake[4]: stopped in /usr/src/tools/gcc
nbmake[4]: 1 error
nbmake[4]: stopped in /usr/src/tools/gcc
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.110 -r1.111 src/tools/gcc/Makefile
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
> Modified files:
>
> Index: src/tools/gcc/Makefile
> diff -u src/tools/gcc/Makefile:1.110 src/tools/gcc/Makefile:1.111
> --- src/tools/gcc/Makefile:1.110 Thu Feb 22 02:40:21 2024
> +++ src/tools/gcc/MakefileThu Feb 22 02:47:26 2024
> @@ -1,4 +1,4 @@
> -#$NetBSD: Makefile,v 1.110 2024/02/22 02:40:21 mrg Exp $
> +#$NetBSD: Makefile,v 1.111 2024/02/22 02:47:26 mrg Exp $
>
> .include
>
> @@ -35,7 +35,6 @@ COMMON_CONFIGURE_ARGS= --target=${MACHIN
>
> --with-bugurl=http://www.NetBSD.org/support/send-pr.html \
> --with-pkgversion="NetBSD ${NETBSD_GCC_VERSION}" \
> --with-system-zlib \
> - --without-isl \
> --enable-__cxa_atexit \
> --enable-libstdcxx-time=rt \
> --enable-libstdcxx-threads \
> @@ -58,12 +57,21 @@ COMMON_CONFIGURE_ARGS+= --enable-fix-cor
> COMMON_CONFIGURE_ARGS+= --with-default-libstdcxx-abi=new
> .endif
>
> +# We nabled isl support for GCC 12. Move into normal segment when
> +# removing GCC 10.
> +.if ${HAVE_GCC} < 12
> +ISL_CONFIGURE_ARGS+= --without-isl
> +.else
> +ISL_CONFIGURE_ARGS+= --with-isl=${TOOLDIR}
> +.endif
> +
> CONFIGURE_ARGS= ${COMMON_CONFIGURE_ARGS}
> CONFIGURE_ARGS+= \
> --with-sysroot=${DESTDIR} \
> --with-mpc=${TOOLDIR} \
> --with-mpfr=${TOOLDIR} \
> --with-gmp=${TOOLDIR} \
> + ${ISL_CONFIGURE_ARGS} \
> --disable-nls \
> ${MULTILIB_ARGS} \
> ${SOFTFLOAT_ARGS} \
>
--
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Re: CVS commit: src/usr.bin/ftp
In article <20240218223315.800aff...@cvs.netbsd.org>, Thomas Klausner wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: wiz >Date: Sun Feb 18 22:33:15 UTC 2024 > >Modified Files: > src/usr.bin/ftp: ftp_var.h > >Log Message: >ftp: bump FTPBUFLEN from 4kB to 16kB > >sourceforge.net returns a 5kB content-security-policy. >Analyzed by mlelstv@ who reports usual limits are between 4kB and 48kB. This is used in two other places unrelated to fetch (one in getline on the stack and one static for completions). While it is ok to increase the default now because I've made it dynamically allocated in the fetch cases, we should probably use a different buffer constant for the other two... christos
Re: CVS commit: src
I made it return EPERM if they are different. christos > On Feb 3, 2024, at 3:58 PM, J. Hannken-Illjes wrote: > >> On 3. Feb 2024, at 19:45, Christos Zoulas wrote: >> >> Oh, I fixed GETARGS, but not UPDATE... How about now? > > What is the expected result if we update a cd9660 mount with different > uid/gid or masks? > > If it is forbidden the "mp->mnt_flag & MNT_UPDATE" case, lines 306 .. 312 > of cd9660_vfsops.c should test them and fail on different values. > > If it is allowed to change them it has to be done here. > >>> On Feb 3, 2024, at 12:48 PM, J. Hannken-Illjes wrote: >>> On 3. Feb 2024, at 18:38, Christos Zoulas wrote: Fixed, thanks. >>> >>> Not really, with "struct iso_args *args = data" you cannot set fields >>> beyond "datalen" here and the MNT_UPDATE case is still missing. > > -- > J. Hannken-Illjes - hann...@mailbox.org
Re: CVS commit: src
> On 3. Feb 2024, at 19:45, Christos Zoulas wrote: > > Oh, I fixed GETARGS, but not UPDATE... How about now? What is the expected result if we update a cd9660 mount with different uid/gid or masks? If it is forbidden the "mp->mnt_flag & MNT_UPDATE" case, lines 306 .. 312 of cd9660_vfsops.c should test them and fail on different values. If it is allowed to change them it has to be done here. >> On Feb 3, 2024, at 12:48 PM, J. Hannken-Illjes wrote: >> >>> On 3. Feb 2024, at 18:38, Christos Zoulas wrote: >>> >>> Fixed, thanks. >> >> Not really, with "struct iso_args *args = data" you cannot set fields >> beyond "datalen" here and the MNT_UPDATE case is still missing. -- J. Hannken-Illjes - hann...@mailbox.org
Re: CVS commit: src
Oh, I fixed GETARGS, but not UPDATE... How about now? christos > On Feb 3, 2024, at 12:48 PM, J. Hannken-Illjes wrote: > >> On 3. Feb 2024, at 18:38, Christos Zoulas wrote: >> >> Fixed, thanks. > > Not really, with "struct iso_args *args = data" you cannot set fields > beyond "datalen" here and the MNT_UPDATE case is still missing. > > -- > J. Hannken-Illjes - hann...@mailbox.org
Re: CVS commit: src
> On 3. Feb 2024, at 18:38, Christos Zoulas wrote: > > Fixed, thanks. Not really, with "struct iso_args *args = data" you cannot set fields beyond "datalen" here and the MNT_UPDATE case is still missing. -- J. Hannken-Illjes - hann...@mailbox.org
Re: CVS commit: src
Fixed, thanks. christos
Re: CVS commit: src
> On 2. Feb 2024, at 21:27, Christos Zoulas wrote: > > Module Name: src > Committed By: christos > Date: Fri Feb 2 20:27:26 UTC 2024 > > Modified Files: > src/sbin/mount_cd9660: Makefile mount_cd9660.8 mount_cd9660.c > src/sys/fs/cd9660: cd9660_extern.h cd9660_mount.h cd9660_vfsops.c >cd9660_vnops.c > > Log Message: > PR/57897: Ricardo Branco: Add support for mount options mask,dirmask,uid,gid > > > To generate a diff of this commit: > cvs rdiff -u -r1.12 -r1.13 src/sbin/mount_cd9660/Makefile > cvs rdiff -u -r1.31 -r1.32 src/sbin/mount_cd9660/mount_cd9660.8 > cvs rdiff -u -r1.33 -r1.34 src/sbin/mount_cd9660/mount_cd9660.c > cvs rdiff -u -r1.27 -r1.28 src/sys/fs/cd9660/cd9660_extern.h > cvs rdiff -u -r1.6 -r1.7 src/sys/fs/cd9660/cd9660_mount.h > cvs rdiff -u -r1.97 -r1.98 src/sys/fs/cd9660/cd9660_vfsops.c > cvs rdiff -u -r1.62 -r1.63 src/sys/fs/cd9660/cd9660_vnops.c First, this is not backwards compatible. An old mount_cd9660 and a new kernel will always return EINVAL as the argument length check on top of cd9660_mount() fires. Second, with these new mount arguments an update mount has to update the masks and ids, currently they are silently ignored. -- J. Hannken-Illjes - hann...@mailbox.org
re: CVS commit: src
"Taylor R Campbell" writes: > Mark /var/run/named obsolete in the set lists. XXX This isn't quite > right, because it is legitimate for /var/run/named to exist in a > running installation, but it doesn't exist in a freshly installed > system any more. Maybe we should just remove the entry from the set > lists and add a note to UPDATING about deleting it manually from the > destdir in incremental builds. i think removing it is right. obsolete removes something that might be in-use, if someone were to run postinstall when named is running (which isn't _too_ unexpected.) thanks. .mrg.
Re: CVS commit: src/usr.bin/make
On Thu, 25 Jan 2024 20:02:00 +0100, Roland Illig writes:
>>> Modified Files:
>>> src/usr.bin/make: make.1
>>>
>>> Log Message:
>>> Indicate that for :U newval is optional
>>
>> I think this is more confusing than helpful.
>
>I agree. Make doesn't distinguish between an empty string and an absent
>string here, so the wording in the manual page should be kept equally
>simple.
Not a question of what make likes or not, but what users glean from the
man page (those that don't also read the source).
The change was prompted by a user (not a make novice by any means)
complaining that :Unewval and the description provides no clue
that just :U is actually valid.
>If anything, you might mention that newval may be empty, but then you'd
I think I started with that, but then figured someone sufficiently
pedantic might consider that not the same as no value being provided ;-)
>have to add the same wording in many other places, for consistency:
>* the variable name in ${:Uvalue}
This is covered by the above no?
>* the two branches of the ':?' modifier in ${cond:?}
true
>* the pattern matching modifiers after ':S,from,to' (1gW)
>* the variable name in the variable assignment '!=3Dcmd'
>* the argument of a function call in '.if defined()'
>
>Most of these cases don't need this wording, and the '!=3Dcmd' case
Agreed, the :S usage at least is sufficiently familiar to anyone who's
used sed(1) to not need elaboration.
Is there perhaps a general statement somewhere (I may have missed it)
that could cover all these and be cited to pedantic users?
Eg to the effect of perhaps, unless stated otherwise arguments to
modifiers are optional or can be empty.
I don't think its there and is hard to word succinctly.
Thanks
--sjg
Re: CVS commit: src/usr.bin/make
On Thu, 25 Jan 2024 21:12:20 +0100, Roland Illig writes: >them all. Due to this, I'd go with: > >> .It Cm \&:U\| Ns Ar newval >> If the variable is undefined, >> .Ar newval >> (which may be empty) is the value. That's almost exactly what I had in my 1st cut ;-) Will do. >Then, add the same wording to ':D' and maybe to ':N' (since ':N' is a >shortcut for the more common ':M*') but not to ':M' itself (as that >would always result in an empty string, making it uninteresting). Will take a look, but not so sure. --sjg
Re: CVS commit: src/usr.bin/make
About optional arguments to modifiers, such as in ${VAR:U}:
Am 25.01.2024 um 20:54 schrieb Simon Gerraty:
> Is there perhaps a general statement somewhere (I may have missed it)
> that could cover all these and be cited to pedantic users?
> Eg to the effect of perhaps, unless stated otherwise arguments to
> modifiers are optional or can be empty.
>
> I don't think its there and is hard to word succinctly.
No, I searched through the manual page but didn't find one.
Also, there are so many syntactic quirks and edge cases in make that I
don't think there's an easy to grasp single-line statement that covers
them all. Due to this, I'd go with:
> .It Cm \&:U\| Ns Ar newval
> If the variable is undefined,
> .Ar newval
> (which may be empty) is the value.
Then, add the same wording to ':D' and maybe to ':N' (since ':N' is a
shortcut for the more common ':M*') but not to ':M' itself (as that
would always result in an empty string, making it uninteresting).
Roland
Re: CVS commit: src/usr.bin/make
Am 25.01.2024 um 14:25 schrieb Valery Ushakov:
> On Thu, Jan 25, 2024 at 07:35:46 +, Simon J. Gerraty wrote:
>
>> Modified Files:
>> src/usr.bin/make: make.1
>>
>> Log Message:
>> Indicate that for :U newval is optional
>
> I think this is more confusing than helpful.
I agree. Make doesn't distinguish between an empty string and an absent
string here, so the wording in the manual page should be kept equally
simple.
If anything, you might mention that newval may be empty, but then you'd
have to add the same wording in many other places, for consistency:
* the variable name in ${:Uvalue}
* the two branches of the ':?' modifier in ${cond:?}
* the pattern matching modifiers after ':S,from,to' (1gW)
* the variable name in the variable assignment '!=cmd'
* the argument of a function call in '.if defined()'
Most of these cases don't need this wording, and the '!=cmd' case
shouldn't be documented at all, as it is a dirty hack.
Roland
Re: CVS commit: src/bin/date
In article <19118.1705868...@jacaranda.noi.kre.to>, Robert Elz wrote: >Date:Sun, 21 Jan 2024 18:16:28 - (UTC) >From:chris...@astron.com (Christos Zoulas) >Message-ID: > > | I think this is the yacc used by the build process, not the yacc > | to build tools with? I.e. will this yacc produce c files usable in > | the host compilation environment? > >I was also looking at that problem, but in a different direction. >Rather than making -d work in the tools date (either by somehow >making parsedate work - which really isn't worth the effort for >this, or via your hack) but by using -j and specifying the date >in canonincal form instead of parsedate random form. > >That is, it is trivial to make > > date -j '+whatever format you like' 202401220314 > >work (including in the tools date), provided you can convert the date >string you're starting with into that canonical form - that takes make >magic, a topic of which I am barely aware exists, let alone competant, >so that was as far as I took it... I should have thought of that, duh. This means adding 4 0's in the Makefile... christos
Re: CVS commit: src/lib/libutil
On Sun, Jan 21, 2024 at 21:31:23 +, Roland Illig wrote: > and also didn't make it clear that a few bits were omitted from > having descriptions. I dislike this part. It's internally inconsistent as it doesn't add the placeholders for the low bits; and in many real-life scenarios there will be *lots* of gaps in the defined bits, so implying in the man page that the placeholders are good style just places the people in a situation where they have to make the sensible thing, but go against the style suggested in the man page. I don't think that's helpful. Please, can we remove the placeholders from this example? -uwe
Re: CVS commit: src/bin/date
Date:Sun, 21 Jan 2024 18:16:28 - (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | I think this is the yacc used by the build process, not the yacc | to build tools with? I.e. will this yacc produce c files usable in | the host compilation environment? I was also looking at that problem, but in a different direction. Rather than making -d work in the tools date (either by somehow making parsedate work - which really isn't worth the effort for this, or via your hack) but by using -j and specifying the date in canonincal form instead of parsedate random form. That is, it is trivial to make date -j '+whatever format you like' 202401220314 work (including in the tools date), provided you can convert the date string you're starting with into that canonical form - that takes make magic, a topic of which I am barely aware exists, let alone competant, so that was as far as I took it... kre
Re: CVS commit: src/bin/date
Am 21.01.2024 um 19:16 schrieb Christos Zoulas: > In article , > Valery Ushakov wrote: >> On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote: >> >>> Consider providing parsedate(3) in libcompat, but then we'd need >>> yacc... >> >> We already have yacc in tools - src/tools/yacc > > I think this is the yacc used by the build process, not the yacc > to build tools with? I.e. will this yacc produce c files usable in > the host compilation environment? From my understanding, tools/yacc runs in the host environment and target the same host environment, as its output is used by tools/lint1, which runs in the host environment but targets the target environment. Or might the output from tools/yacc even be platform-independent? Roland
Re: CVS commit: src/bin/date
In article , Valery Ushakov wrote: >On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote: > >> Consider providing parsedate(3) in libcompat, but then we'd need >> yacc... > >We already have yacc in tools - src/tools/yacc I think this is the yacc used by the build process, not the yacc to build tools with? I.e. will this yacc produce c files usable in the host compilation environment? christos
Re: CVS commit: src/bin/date
On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote: > Consider providing parsedate(3) in libcompat, but then we'd need > yacc... We already have yacc in tools - src/tools/yacc -uwe
Re: CVS commit: src/sys/arch/macppc/conf
On Thu, Jan 18, 2024 at 06:43:21 +1100, matthew green wrote: > > Log Message: > > macppc: enable FFS_EI in GENERIC > > > > I'd say it should be enabled for anything with USB. > > > > ok macallan > > yay. i think we should enable it basically everywhere that it > is not a space issue. I think the size impact should be trivial (though I didn't measure). The option basically guards just a couple dozens of "bit test plus bswap call" snippets. > USB is just one common way, but i can also modify or create my own > images anyway, and maybe copy them over the network to my machine > with USB...or maybe i'll setup the disk on this machine's scsi for > that machine ;) Yeah. I just didn't want to open that can of yaks to shave... :) -uwe
re: CVS commit: src/sys/arch/macppc/conf
> Log Message: > macppc: enable FFS_EI in GENERIC > > I'd say it should be enabled for anything with USB. > > ok macallan yay. i think we should enable it basically everywhere that it is not a space issue. USB is just one common way, but i can also modify or create my own images anyway, and maybe copy them over the network to my machine with USB...or maybe i'll setup the disk on this machine's scsi for that machine ;)
Re: CVS commit: src/sys/arch
> No, that definitely wasn't intentional! I've just reverted > that. Does that need a pullup for netbsd-10 ? Thanks for your confirmation. I have another fix to make GENERIC boot on my 3/60 (disable more several pseudo-devices to shrink binary) so I'll handle a pullup request with your fix. --- Izumi Tsutsui
Re: CVS commit: src/sys/arch
Hi Tsutsui, Izumi Tsutsui wrote: > simonb@ wrote: > > > cvs rdiff -u -r1.187 -r1.188 src/sys/arch/sun3/conf/GENERIC > > >> # Veriexec > >> # include "dev/veriexec.config" > >> + > >> +no obmem0 at mainbus? # XX > > Is this intentional!? No, that definitely wasn't intentional! I've just reverted that. Does that need a pullup for netbsd-10 ? Cheers, Simon.
Re: CVS commit: src/sys/arch
simonb@ wrote: > Module Name: src > Committed By: simonb > Date: Sun Aug 7 02:52:30 UTC 2022 > > Modified Files: : > src/sys/arch/sun3/conf: DISKLESS GENERIC GENERIC3X : > Log Message: > UFS/LFS dirhash: > - Enable UFS_DIRHASH if the architecture or kernel model specific config > file can use 128MB of RAM or more. > - Remove experimental tag from UFS_DIRHASH; it's been with RUMP kernel > and by a number of NetBSD developers for years. > - Add LFS_DIRHASH if LFS was enabled. > - Be somewhat consistent with FS options order. : > cvs rdiff -u -r1.187 -r1.188 src/sys/arch/sun3/conf/GENERIC >> # Veriexec >> # include "dev/veriexec.config" >> + >> +no obmem0 at mainbus? # XX Is this intentional!? --- Izumi Tsutsui
Re: CVS commit: src/sys/sys
In article <2017973.usquhbg...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Tue Jan 2 19:27:57 UTC 2024 >> >> Modified Files: >> src/sys/sys: rbtree.h >> >> Log Message: >> This uses size_t, so it always needs , remove ifdefs. > >sys/types.h is one of the most polluting headers we have. This is a huge >step backwards... You realize of course that it was working before because it was getting sys/types.h from sys/endian.h which had an include cycle before which I was trying to fix. Now sys/endian.h does not include sys/types.h which is a step forward. Yes, our headers are messy but we are trying to clean them. Happy New Year, christos
Re: CVS commit: src/share/mk
I would also prefer current general "virt68k", rather than specific emulators like qemu68k etc. because: - it's unlikely that someone will design and implement new virtual Ethernet/storage I/O devices for ancient architectures - we should avoid dumb copies of MD locore.s, pmap_bootstrap.c, headers, and src/distrib files etc. - even if we will support different VM implementation, we can still have multiple kernel config files in a single port, as we've merged sun3 (020 + Sun's MMU) and sun3x (030 MMU) into a single sun3 port in the past (atari and evbarm also have multiple GENERIC like config files for different archtectures) Thanks, --- Izumi Tsutsui
Re: CVS commit: src/share/mk
> On Jan 3, 2024, at 9:16 AM, Jason Thorpe wrote: > > There’s really nothing Qemu specific about it, other than Qemu version number > extraction. Let me elaborate, actually, now that I am not constrained by thumbs-only typing. It uses the generic Linux m68k “bootinfo”, which specify the machine type and address of the various devices, and provisions for how reset/halt are handled are also dealt with generically. Every Linux m68k platform uses this mechanism and I would be shocked (SHOCKED) if some hypothetical future non-Qemu m68k VirtIO platform did not support Linux natively. The Qemu version extraction is actually done with one of those “bootinfo” records. There are really only two assumptions that are made: - RAM starts at PA $., the kernel starts with the MMU disabled, and is loaded at its link address. - I/O devices start at PA $FF00., and that they can be mapped VA==PA with a TT register. The latter would be pretty easy to deal with dynamically if the situation arose. And the former would be possible to adapt to if that assumption were to suddenly not be valid. Heck, the hp300 kernel is linked at VA=$. and knows how to deal with the start of RAM varying based on how much memory is installed (whereas the end of RAM is always at the same location, at the top of the physical address space. Weirdos.) -- thorpej
Re: CVS commit: src/share/mk
There’s really nothing Qemu specific about it, other than Qemu version number extraction. -- thorpej Sent from my iPhone. > On Jan 2, 2024, at 11:03 PM, Valery Ushakov wrote: > > On Wed, Jan 03, 2024 at 02:48:06 +, Jason R Thorpe wrote: > >> Add virt68k to MACHINES.m68k. > > "virt" is too generic a name, if this is specifically a qemu version, > may be it should have been called qemu68k... Guess it's too late now. > > -uwe
Re: CVS commit: src/share/mk
On Wed, Jan 03, 2024 at 02:48:06 +, Jason R Thorpe wrote: > Add virt68k to MACHINES.m68k. "virt" is too generic a name, if this is specifically a qemu version, may be it should have been called qemu68k... Guess it's too late now. -uwe
Re: CVS commit: src/sys/sys
Date:Tue, 2 Jan 2024 21:20:42 -0500 From:Jason Thorpe Message-ID: | seems safe Safe probably, but also wrong. It looks to be there puerly for the __BEGIN_DECLS / __END_DECLS definitions - which are needed just beause has prototypes for lseek() truncate() and ftruncate() which make no sense in at all (beyond ancient history). kre
Re: CVS commit: src/sys/sys
> On Jan 2, 2024, at 8:41 PM, Robert Elz wrote: > > I doubt that should really be including > and almost certainly not , and shouldn't have prototypes > for any functions at all. seems safe — all of that stuff is in the implementation namespace. -- thorpej
Re: CVS commit: src/sys/sys
Date:Wed, 3 Jan 2024 03:15:39 +0300 From:Valery Ushakov Message-ID: | for userland uses should include stddef.h where size_t is supposed | to come from Unfortunately, while is defined to specify size_t it isn't specified to include ssize_t - and many things that need size_t also need ssize_t (which includes src/usr.bin/tprof one of the users of ) All of this is horribly ugly - perhaps we'd do better to remove stuff from that shouldn't be there (which is probably any definition which doesn't end in _t except probably the old u_char u_short ... and their uchar/ushort/... variants). In particular I doubt that should really be including and almost certainly not , and shouldn't have prototypes for any functions at all. kre
Re: CVS commit: src/sys/sys
On Wed, Jan 03, 2024 at 01:06:57 +0100, Joerg Sonnenberger wrote: > Date: Wed, 03 Jan 2024 01:06:57 +0100 > From: Joerg Sonnenberger > Subject: Re: CVS commit: src/sys/sys > To: source-changes-d@netbsd.org > > On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote: > > Module Name:src > > Committed By: christos > > Date: Tue Jan 2 19:27:57 UTC 2024 > > > > Modified Files: > > src/sys/sys: rbtree.h > > > > Log Message: > > This uses size_t, so it always needs , remove ifdefs. > > sys/types.h is one of the most polluting headers we have. This is a huge > step backwards... Yes, I think we should keep the ifdef and for userland uses should include stddef.h where size_t is supposed to come from (is inttypes.h really needed there, or is it it just b/c it happens to include most of the same stuff that stddef.h does and hence define size_t?) -uwe
Re: CVS commit: src/sys/sys
On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Tue Jan 2 19:27:57 UTC 2024 > > Modified Files: > src/sys/sys: rbtree.h > > Log Message: > This uses size_t, so it always needs , remove ifdefs. sys/types.h is one of the most polluting headers we have. This is a huge step backwards... Joerg
Re: CVS commit: src/tests/bin/sh
On Thu, Dec 28, 2023 at 11:08 PM Robert Elz wrote: > > [I could claim that the typo was deliberate, as part of > the test but that would be kind of absurd, sh does > no spell checking to test.] > > kre > Thanks for clarification. I definitely had few instances when I needed to revert spelling fixes, which were left on purpose for one reason or another, fortunately it is not the case here :).
Re: CVS commit: src/tests/bin/sh
Date:Thu, 28 Dec 2023 20:04:11 + From:"Andrius Varanavicius" Message-ID: <20231228200411.283ccf...@cvs.netbsd.org> | Modified Files: | src/tests/bin/sh: t_syntax.sh | Log Message: | s/synax/syntax/ in test description. Thanks for the correction, but, not that it matters, that was in the test code, not just a description. [I could claim that the typo was deliberate, as part of the test but that would be kind of absurd, sh does no spell checking to test.] kre
re: CVS commit: src/sys/dev/usb
"Nick Hudson" writes: > Module Name: src > Committed By: skrll > Date: Tue Dec 19 07:05:36 UTC 2023 > > Modified Files: > src/sys/dev/usb: if_axen.c > > Log Message: > Add support for AX88179A. From sc.dying on current-users. > > > To generate a diff of this commit: > cvs rdiff -u -r1.94 -r1.95 src/sys/dev/usb/if_axen.c cool. this can probably go back to not having a device softc by using un_flags: /* * This section is for driver to use, not touched by usbnet. */ unsignedun_flags; in struct usbnet, and axen_softc becomes just usbnet again. .mrg.
