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.
Re: CVS commit: src/sys/arch/sparc64
Hi, Will check and adjust. Thanks for the tip. On Thu, Dec 14, 2023 at 2:12 AM Valery Ushakov wrote: > > On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote: > > > Module Name: src > > Committed By: andvar > > Date: Wed Dec 13 23:11:35 UTC 2023 > > > > Modified Files: > > src/sys/arch/sparc64/dev: vnet.c > > src/sys/arch/sparc64/sparc64: netbsd32_machdep_13.c > > > > Log Message: > > Add #ifdef DDB blocks around Debugger(); calls to make kernel build without > > DDB. > > May be use console_debugger() that from a quick look seems to do the > right thing already (including db_fromconsole guard)? > > -uwe >
Re: CVS commit: src/sys/arch/sparc64
On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote: > Module Name: src > Committed By: andvar > Date: Wed Dec 13 23:11:35 UTC 2023 > > Modified Files: > src/sys/arch/sparc64/dev: vnet.c > src/sys/arch/sparc64/sparc64: netbsd32_machdep_13.c > > Log Message: > Add #ifdef DDB blocks around Debugger(); calls to make kernel build without > DDB. May be use console_debugger() that from a quick look seems to do the right thing already (including db_fromconsole guard)? -uwe
Re: CVS commit: src/lib/libc/time
Valery Ushakov wrote in : |On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote: | |> On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote: |> |>> While here, consistemntly use minus when minus is meant, rather that |>> just using a hyphen. |> |> One has to be careful with this. | |And to have this on record for refernce: https://lwn.net/Articles/947941/ 'Could be you like that: https://lists.gnu.org/archive/html/groff/2022-09/msg00048.html (or these https://lists.gnu.org/archive/html/groff/2022-09/msg00053.html https://lists.gnu.org/archive/html/groff/2022-09/msg00057.html heck i could vomit all thread long. :-) |-uwe --End of Ciao. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only in December: lightful Dubai COP28 Narendra Modi quote: | A small part of humanity has ruthlessly exploited nature. | But the entire humanity is bearing the cost of it, | especially the inhabitants of the Global South. | The selfishness of a few will lead the world into darkness, | not just for themselves but for the entire world.
Re: CVS commit: src/lib/libc/time
On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote: > On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote: > > > While here, consistemntly use minus when minus is meant, rather that > > just using a hyphen. > > One has to be careful with this. And to have this on record for refernce: https://lwn.net/Articles/947941/ -uwe
Re: CVS commit: src/lib/libc/time
On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote: > While here, consistemntly use minus when minus is meant, rather that > just using a hyphen. One has to be careful with this. In the literal context (Ql, Li, etc) the ascii minus-hyphen in the input is preserved as such. In other contexts you will get a math minus sign in PS/PDF output, or groff UTF-8 text output, which makes man page not copy-pastable. And wide (about the size of en-dash) minus sign looks rather ugly in non math contexts like 02:00 CST (−06) in PS/PDF. -uwe
Re: CVS commit: src/share/man/man7
On Sat, Nov 25, 2023 at 11:36:34 -0800, Alistair Crooks wrote: > I find it better to have > > MAN+= bar.7 > MAN+= foo.7 > > Since a grep for 'MAN.*foo' will produce meaningful results Also good for diffs in the future, e.g. MAN += f.3 -MAN += g.3 MAN += h.3 vs. f.3 \ -g.3 \ h.3 \ Diff -p *might* do the helpful thing, but it gets confused sometimes. -uwe
Re: CVS commit: src/share/man/man7
On Fri, Nov 24, 2023 at 18:09 Taylor R Campbell < campbell+netbsd-source-change...@mumble.net> wrote: > > Date: Sat, 25 Nov 2023 02:05:25 + > > From: Taylor R Campbell > > > > > Date: Sat, 25 Nov 2023 00:23:33 - (UTC) > > > From: chris...@astron.com (Christos Zoulas) > > > > > > Yes, this is indeed a lot better. I prefer though: > > > > > > MAN+= \ > > > bar.7 \ > > > foo.7 > > > > > > It is faster to parse, involves less typing, whitespace is cleaner. > > > > This one doesn't have the same pattern for every line, so it makes > > merging and sorting harder -- do M-x sort-lines on the content lines, > > and you'll come up with: > > > > MAN+= \ > > foo.7 > > bar.7 \ > > err, obviously I meant this example the other way; if it had been > written as: > > MAN+= \ > foo.7 \ > bar.7 > > as the natural order of metasyntactic variables (foo, bar), then doing > M-x sort-lines on the content lines would yield: > > MAN+= \ > bar.7 > foo.7 \ I find it better to have MAN+= bar.7 MAN+= foo.7 Since a grep for 'MAN.*foo' will produce meaningful results Sorting, and initial entry are once-only operations, searching happens everywhere all the time. > > >
Re: CVS commit: src/share/man/man7
> Date: Sat, 25 Nov 2023 02:05:25 + > From: Taylor R Campbell > > > Date: Sat, 25 Nov 2023 00:23:33 - (UTC) > > From: chris...@astron.com (Christos Zoulas) > > > > Yes, this is indeed a lot better. I prefer though: > > > > MAN+= \ > > bar.7 \ > > foo.7 > > > > It is faster to parse, involves less typing, whitespace is cleaner. > > This one doesn't have the same pattern for every line, so it makes > merging and sorting harder -- do M-x sort-lines on the content lines, > and you'll come up with: > > MAN+= \ > foo.7 > bar.7 \ err, obviously I meant this example the other way; if it had been written as: MAN+= \ foo.7 \ bar.7 as the natural order of metasyntactic variables (foo, bar), then doing M-x sort-lines on the content lines would yield: MAN+= \ bar.7 foo.7 \
Re: CVS commit: src/share/man/man7
> Date: Sat, 25 Nov 2023 00:23:33 - (UTC) > From: chris...@astron.com (Christos Zoulas) > > Yes, this is indeed a lot better. I prefer though: > > MAN+= \ > bar.7 \ > foo.7 > > It is faster to parse, involves less typing, whitespace is cleaner. This one doesn't have the same pattern for every line, so it makes merging and sorting harder -- do M-x sort-lines on the content lines, and you'll come up with: MAN+= \ foo.7 bar.7 \ which does the wrong thing, and only if you're lucky will fail in an obvious way rather than just silently omitting some entries. In portable makefiles I usually write: MAN= \ bar.7 \ foo.7 \ # end of MAN so at least each line has the same pattern, making merging and sorting easier.
Re: CVS commit: src/share/man/man7
In article <20231123211614.011a1f...@cvs.netbsd.org>, Taylor R Campbell wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: riastradh >Date: Thu Nov 23 21:16:13 UTC 2023 > >Modified Files: > src/share/man/man7: Makefile > >Log Message: >share/man/man7/Makefile: Split MAN on separate lines, and sort. > >Makes sorting and merging changes easier. > >No functional change intended. > >Preparing for a new stack(7) in the service of PR pkg/57708. Yes, this is indeed a lot better. I prefer though: MAN+= \ bar.7 \ foo.7 It is faster to parse, involves less typing, whitespace is cleaner. christos
Re: CVS commit: src/lib/libc/ssp
On Wednesday, November 15, 2023 4:15:28 AM CET you wrote: > Module Name: src > Committed By: christos > Date: Wed Nov 15 03:15:28 UTC 2023 > > Modified Files: > src/lib/libc/ssp: Makefile.inc > Added Files: > src/lib/libc/ssp: ssp_redirect.c > > Log Message: > provide materialized functions for the ssp overriden inlines The functions are supposed to be transparent and they used to be. Can we please just go back to the working state before? IMO wanting to overriding getcwd is absolutely no justification for this. If the prototype (and inline function) is visible from the header, userland should *not* be abled to interpose it. If it is not visible due to standard headers, there was no problem in first place. Joerg
Re: CVS commit: src/sys/arch/mips/mips
Thank you, I should pay attention to that. On Wed, Oct 25, 2023 at 9:02 AM Nick Hudson wrote: > > Module Name:src > Committed By: skrll > Date: Wed Oct 25 06:02:14 UTC 2023 > > Modified Files: > src/sys/arch/mips/mips: kgdb_machdep.c > > Log Message: > -> > > > To generate a diff of this commit: > cvs rdiff -u -r1.21 -r1.22 src/sys/arch/mips/mips/kgdb_machdep.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/tests/sbin/ifconfig
On 2023/10/18 17:25, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Wed Oct 18 08:25:14 UTC 2023 Modified Files: src/tests/sbin/ifconfig: t_capabilities.sh Log Message: ifconfig/t_capabilities: Skip unless run_unsafe is configured to yes The test modifies if_capabilities for all available interfaces. This is not a behavior we expect for normal ATF runs. s/if_capabilities/if_capenable/ here. Thanks, rin
Re: CVS commit: src/sys/dev/pci/ixgbe
On 2023/10/12 14:50, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Thu Oct 12 05:50:56 UTC 2023 > > Modified Files: > src/sys/dev/pci/ixgbe: ixgbe.c > > Log Message: > ixg(4): Don't print wrong error message about ixgbe_num_queues. > > Don't override the ixgbe_num_queues global variable. It's the default > value of the number of queues and should not override it because it > will be referenced by later device attach. For example, the number of > MSI-X vector is 64 on X540 and 18 on 82599. When both cards are inserted > to a machine that the number of CPU is 24 and X540 is probed earlier, > ixgbe_num_queues is overridden to 24 and the following error message is > printed when attaching 82599: > > ixg2: autoconfiguration error: ixgbe_num_queues (24) is too large, > using reduced amount (17). > > Note that the number of queues is in sc->num_queuss and referenced > by hw.ixgN.num_queues sysctl. The commit message was incorrect. - s/82599/82598/ - Worse thing can happen if a smaller number of MSI-X vector's device is attached earlier. The small number is set as the default value and the number of queues of the next device is unintentionally limited to it. > To generate a diff of this commit: > cvs rdiff -u -r1.341 -r1.342 src/sys/dev/pci/ixgbe/ixgbe.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/dev/pci/igc
On 2023-10-15 17.06, Joerg Sonnenberger wrote: On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote: Module Name:src Committed By: oster Date: Sun Oct 15 22:36:53 UTC 2023 Modified Files: src/sys/dev/pci/igc: if_igc.c Log Message: Fix build of the MODULAR kernel, which explicitly excludes vlans. Please fix the macro to not expand to nothing instead. I think you're referring to the change I made to src/sys/dev/sequencer.c instead of this one... Done! Later... Greg Oster
Re: CVS commit: src/sys/dev/pci/igc
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote: > Module Name: src > Committed By: oster > Date: Sun Oct 15 22:36:53 UTC 2023 > > Modified Files: > src/sys/dev/pci/igc: if_igc.c > > Log Message: > Fix build of the MODULAR kernel, which explicitly excludes vlans. Please fix the macro to not expand to nothing instead. Joerg
Re: CVS commit: src/sys
> Date: Fri, 13 Oct 2023 19:03:35 + > From: Andrew Doran > > On Thu, Oct 12, 2023 at 11:55:46AM +0200, J. Hannken-Illjes wrote: > > This is not true for RUMP. Hero you added sleepq_remove() as > > "sleepq_unsleep(l, true)". This will unlock l_mutex without changing. > > > > Just poking around and using sleepq_unsleep(l, false) here makes the > > NFS tests using rump_server pass. > > Ah, now I see, thank you. I committed a fix and will do a test run once my > build completes. Thanks, testbed looks much better now!
re: CVS commit: src/lib/libc/stdlib
> Minor changes to jemalloc100 (the old one that only vax etc currently uses). thanks. i'm still using this version on a bunch of modern machines. new jemalloc was problematic for a few things for me a number of years ago and i keep meaning to test again, but for now i'm still mostly using this version everwhere. FYI. .mrg.
Re: CVS commit: src/sys
On Thu, Oct 12, 2023 at 11:55:46AM +0200, J. Hannken-Illjes wrote: > > On 10. Oct 2023, at 20:58, Andrew Doran wrote: > > > > On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote: > > > >>> cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c > >> > >> -sleepq_unsleep(l, false); > >> +sleepq_remove(l->l_sleepq, l, true); > >>} > >> } > >> mutex_spin_exit(lock); > >> > >> Looks like sleepq_remove() unlocks l->l_mutex == lock and > >> then mutex_spin_exit(lock) will unlock an unlocked mutex. > > > > lock is held before the call to sleepq_remove() and this is also true at the > > time: l->l_mutex == lock. > > > > After the call lock is still held, but now l->l_mutex != lock, because l has > > changed state (e.g LSSLEEP -> LSRUN) which causes l_mutex to change in > > concert. There is a rough overview here: > > > > https://nxr.netbsd.org/xref/src/sys/kern/kern_lwp.c#156 > > > > Did you encounter a problem? > > This is not true for RUMP. Hero you added sleepq_remove() as > "sleepq_unsleep(l, true)". This will unlock l_mutex without changing. > > Just poking around and using sleepq_unsleep(l, false) here makes the > NFS tests using rump_server pass. Ah, now I see, thank you. I committed a fix and will do a test run once my build completes. Cheers, Andrew
Re: CVS commit: src/sys/kern
> Date: Fri, 13 Oct 2023 17:52:07 +0900 > From: Rin Okuyama > > It would be really nice if we can find some systematical/reliable methods to > figure out files that really depends on struct syncobj, e.g.. I tried > ctfdump(1) to > *.o for kernel modules, but I cannot extract information better than > ``grep syncobj.h .depend''... The attached patch removes all use of sys/syncobj.h outside .c files under sys, so we can be reasonably confident userland programs -- except for crash(8), which is kind of special -- are unaffected. However, I'm going to hold off on committing this until the tree's sleepq issues are fixed so our testbed can run again. >From 7e9e2af19ecc6f4262b928da8a97a49d171c8072 Mon Sep 17 00:00:00 2001 From: Taylor R Campbell Date: Fri, 13 Oct 2023 11:04:20 + Subject: [PATCH] sys/lwp.h: Nix sys/syncobj.h dependency. Remove it in ddb/db_syncobj.h too. New sys/wchan.h defines wchan_t so that users need not pull in sys/syncobj.h to get it. Sprinkle #include in .c files where it is now needed. --- sys/ddb/db_syncobj.h | 2 +- sys/kern/kern_condvar.c | 1 + sys/kern/kern_ktrace.c| 1 + sys/kern/kern_lwp.c | 1 + sys/kern/kern_mutex.c | 1 + sys/kern/kern_rwlock.c| 1 + sys/kern/kern_sleepq.c| 1 + sys/kern/kern_turnstile.c | 1 + sys/kern/sys_lwp.c| 1 + sys/kern/sys_select.c | 1 + sys/sys/lwp.h | 2 +- sys/sys/sleepq.h | 2 +- sys/sys/sleeptab.h| 6 +- sys/sys/syncobj.h | 4 ++-- sys/sys/wchan.h | 37 + 15 files changed, 56 insertions(+), 6 deletions(-) create mode 100644 sys/sys/wchan.h diff --git a/sys/ddb/db_syncobj.h b/sys/ddb/db_syncobj.h index 2c2ad89ba177..dc7594f5163e 100644 --- a/sys/ddb/db_syncobj.h +++ b/sys/ddb/db_syncobj.h @@ -29,7 +29,7 @@ #ifndef_DDB_DB_SYNCOBJ_H #define_DDB_DB_SYNCOBJ_H -#include +#include struct lwp; struct syncobj; diff --git a/sys/kern/kern_condvar.c b/sys/kern/kern_condvar.c index 478c4a35ff2b..c25282e1beb3 100644 --- a/sys/kern/kern_condvar.c +++ b/sys/kern/kern_condvar.c @@ -45,6 +45,7 @@ __KERNEL_RCSID(0, "$NetBSD: kern_condvar.c,v 1.59 2023/10/12 23:51:05 ad Exp $") #include #include #include +#include /* * Accessors for the private contents of the kcondvar_t data type. diff --git a/sys/kern/kern_ktrace.c b/sys/kern/kern_ktrace.c index 5ad5272af7d8..812be0c2c9ca 100644 --- a/sys/kern/kern_ktrace.c +++ b/sys/kern/kern_ktrace.c @@ -77,6 +77,7 @@ __KERNEL_RCSID(0, "$NetBSD: kern_ktrace.c,v 1.182 2022/07/01 01:07:56 riastradh #include #include #include +#include #include #include diff --git a/sys/kern/kern_lwp.c b/sys/kern/kern_lwp.c index 77e43242f0f9..971e0180f1f6 100644 --- a/sys/kern/kern_lwp.c +++ b/sys/kern/kern_lwp.c @@ -253,6 +253,7 @@ __KERNEL_RCSID(0, "$NetBSD: kern_lwp.c,v 1.265 2023/10/05 19:41:06 ad Exp $"); #include #include #include +#include #include #include diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c index 810ea121a0bd..640909bc533e 100644 --- a/sys/kern/kern_mutex.c +++ b/sys/kern/kern_mutex.c @@ -57,6 +57,7 @@ __KERNEL_RCSID(0, "$NetBSD: kern_mutex.c,v 1.110 2023/09/23 18:48:04 ad Exp $"); #include #include #include +#include #include diff --git a/sys/kern/kern_rwlock.c b/sys/kern/kern_rwlock.c index 88db7d507b4d..96312874a069 100644 --- a/sys/kern/kern_rwlock.c +++ b/sys/kern/kern_rwlock.c @@ -62,6 +62,7 @@ __KERNEL_RCSID(0, "$NetBSD: kern_rwlock.c,v 1.74 2023/10/04 20:39:35 ad Exp $"); #include #include #include +#include #include diff --git a/sys/kern/kern_sleepq.c b/sys/kern/kern_sleepq.c index e9d39445f75b..bb43e78f6f6b 100644 --- a/sys/kern/kern_sleepq.c +++ b/sys/kern/kern_sleepq.c @@ -49,6 +49,7 @@ __KERNEL_RCSID(0, "$NetBSD: kern_sleepq.c,v 1.83 2023/10/08 13:37:26 ad Exp $"); #include #include #include +#include /* * for sleepq_abort: diff --git a/sys/kern/kern_turnstile.c b/sys/kern/kern_turnstile.c index 0cd8886cb6b5..85bdf946c325 100644 --- a/sys/kern/kern_turnstile.c +++ b/sys/kern/kern_turnstile.c @@ -68,6 +68,7 @@ __KERNEL_RCSID(0, "$NetBSD: kern_turnstile.c,v 1.53 2023/10/08 13:23:05 ad Exp $ #include #include #include +#include #include /* diff --git a/sys/kern/sys_lwp.c b/sys/kern/sys_lwp.c index c71cf1e823d6..108d40641e38 100644 --- a/sys/kern/sys_lwp.c +++ b/sys/kern/sys_lwp.c @@ -51,6 +51,7 @@ __KERNEL_RCSID(0, "$NetBSD: sys_lwp.c,v 1.87 2023/10/08 13:23:05 ad Exp $"); #include #include #include +#include #include diff --git a/sys/kern/sys_select.c b/sys/kern/sys_select.c index 9719d220e319..16962505663c 100644 --- a/sys/kern/sys_select.c +++ b/sys/kern/sys_select.c @@ -106,6 +106,7 @@ __KERNEL_RCSID(0, "$NetBSD: sys_select.c,v 1.64 2023/10/08 13:23:05 ad Exp $"); #include #include #include +#include /* Flags for lwp::l_selflag. */ #defineSEL_RESET 0 /* awoken, interrupted, or not yet
Re: CVS commit: src/sys
> Date: Tue, 10 Oct 2023 18:58:29 + > From: Andrew Doran > > On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote: > > > > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c > > > > -sleepq_unsleep(l, false); > > +sleepq_remove(l->l_sleepq, l, true); > > } > >} > >mutex_spin_exit(lock); > > > > Looks like sleepq_remove() unlocks l->l_mutex == lock and > > then mutex_spin_exit(lock) will unlock an unlocked mutex. > [...] > Did you encounter a problem? Yes, this appears to be breaking hundreds of automatic tests, which is getting in the way of all kernel testing. https://mail-index.netbsd.org/current-users/2023/10/13/msg044522.html https://mail-index.netbsd.org/current-users/2023/10/13/msg044523.html https://mail-index.netbsd.org/current-users/2023/10/13/msg044524.html Enough breakage has happened over several days that bracket is unable to discern which changes have broken which tests now: https://mail-index.netbsd.org/current-users/2023/10/13/msg044525.html https://mail-index.netbsd.org/current-users/2023/10/13/msg044526.html Please fix immediately or back out.
Re: CVS commit: src/sys/kern
On Thu, Oct 12, 2023 at 8:23 PM Taylor R Campbell wrote: > > > Date: Thu, 12 Oct 2023 17:06:02 +0900 > > From: Rin Okuyama > > > > On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote: > > > > > > Module Name:src > > > Committed By: ad > > > Date: Wed Oct 4 20:39:35 UTC 2023 > > > > > > Modified Files: > > > src/sys/kern: kern_rwlock.c kern_turnstile.c > > > > > > Log Message: > > > Turnstiles: use the syncobj name for ps/top wmesg when sleeping since it's > > > more informative than "tstile". > > > > Cool! Can I send a pull up request to netbsd-10? > > Not sure -- it would depend on this commit to introduce struct > syncobj::sobj_name: > > https://mail-index.netbsd.org/source-changes/2023/07/17/msg146058.html > > This is a potential kernel ABI change. I didn't investigate to > determine whether it would be safe to pull up. Thanks, I didn't notice that. It should be too risky to pull these up just before RC1. I withdraw this proposal. PS It would be really nice if we can find some systematical/reliable methods to figure out files that really depends on struct syncobj, e.g.. I tried ctfdump(1) to *.o for kernel modules, but I cannot extract information better than ``grep syncobj.h .depend''... Thanks, rin
Re: CVS commit: src/sys/kern
> Date: Thu, 12 Oct 2023 17:06:02 +0900 > From: Rin Okuyama > > On Thu, Oct 5, 2023 at 5:39â¯AM Andrew Doran wrote: > > > > Module Name:src > > Committed By: ad > > Date: Wed Oct 4 20:39:35 UTC 2023 > > > > Modified Files: > > src/sys/kern: kern_rwlock.c kern_turnstile.c > > > > Log Message: > > Turnstiles: use the syncobj name for ps/top wmesg when sleeping since it's > > more informative than "tstile". > > Cool! Can I send a pull up request to netbsd-10? Not sure -- it would depend on this commit to introduce struct syncobj::sobj_name: https://mail-index.netbsd.org/source-changes/2023/07/17/msg146058.html This is a potential kernel ABI change. I didn't investigate to determine whether it would be safe to pull up.
Re: CVS commit: src/sys
> On 10. Oct 2023, at 20:58, Andrew Doran wrote: > > On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote: > >>> cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c >> >> -sleepq_unsleep(l, false); >> +sleepq_remove(l->l_sleepq, l, true); >>} >> } >> mutex_spin_exit(lock); >> >> Looks like sleepq_remove() unlocks l->l_mutex == lock and >> then mutex_spin_exit(lock) will unlock an unlocked mutex. > > lock is held before the call to sleepq_remove() and this is also true at the > time: l->l_mutex == lock. > > After the call lock is still held, but now l->l_mutex != lock, because l has > changed state (e.g LSSLEEP -> LSRUN) which causes l_mutex to change in > concert. There is a rough overview here: > > https://nxr.netbsd.org/xref/src/sys/kern/kern_lwp.c#156 > > Did you encounter a problem? This is not true for RUMP. Hero you added sleepq_remove() as "sleepq_unsleep(l, true)". This will unlock l_mutex without changing. Just poking around and using sleepq_unsleep(l, false) here makes the NFS tests using rump_server pass. -- J. Hannken-Illjes - hann...@mailbox.org signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/sys/kern
Cool! Can I send a pull up request to netbsd-10? I've not yet observed deadlocks since this was committed, fortunately or unfortunately, although ;) Thanks, rin On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote: > > Module Name:src > Committed By: ad > Date: Wed Oct 4 20:39:35 UTC 2023 > > Modified Files: > src/sys/kern: kern_rwlock.c kern_turnstile.c > > Log Message: > Turnstiles: use the syncobj name for ps/top wmesg when sleeping since it's > more informative than "tstile". > > > To generate a diff of this commit: > cvs rdiff -u -r1.73 -r1.74 src/sys/kern/kern_rwlock.c > cvs rdiff -u -r1.51 -r1.52 src/sys/kern/kern_turnstile.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/sys
On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote: > > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c > > -sleepq_unsleep(l, false); > +sleepq_remove(l->l_sleepq, l, true); > } >} >mutex_spin_exit(lock); > > Looks like sleepq_remove() unlocks l->l_mutex == lock and > then mutex_spin_exit(lock) will unlock an unlocked mutex. lock is held before the call to sleepq_remove() and this is also true at the time: l->l_mutex == lock. After the call lock is still held, but now l->l_mutex != lock, because l has changed state (e.g LSSLEEP -> LSRUN) which causes l_mutex to change in concert. There is a rough overview here: https://nxr.netbsd.org/xref/src/sys/kern/kern_lwp.c#156 Did you encounter a problem? Cheers, Andrew
Re: CVS commit: src/sys
> On 8. Oct 2023, at 15:23, Andrew Doran wrote: > > Module Name: src > Committed By: ad > Date: Sun Oct 8 13:23:05 UTC 2023 > > Modified Files: > src/sys/kern: kern_condvar.c kern_sleepq.c kern_timeout.c >kern_turnstile.c sys_lwp.c sys_select.c > src/sys/rump/librump/rumpkern: sleepq.c > src/sys/sys: sleepq.h syncobj.h > > Log Message: > Ensure that an LWP that has taken a legitimate wakeup never produces an > error code from sleepq_block(). Then, it's possible to make cv_signal() > work as expected and only ever wake a singular LWP. > > > To generate a diff of this commit: ... > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c -sleepq_unsleep(l, false); +sleepq_remove(l->l_sleepq, l, true); } } mutex_spin_exit(lock); Looks like sleepq_remove() unlocks l->l_mutex == lock and then mutex_spin_exit(lock) will unlock an unlocked mutex. -- J. Hannken-Illjes - hann...@mailbox.org signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/sys/arch/news68k/conf
OK, it makes sense. I will revert the changes. Thanks for your explanations. On Sun, Oct 8, 2023 at 12:49 PM matthew green wrote: > > > I was changing news68k specific code, thus wasn't treating them as > > common. But I understand the point. > > there's a *LOT* of m68k code that is copied into all the ports > that is almost identical, and should really be shared, but it > not, and changes like can make this harder to share. > > ie, while it might appear news68k specific, ideally most of it > would end up in arch/m68k instead. > > it would really be far better for that merge, than to worry > about obscure compile options -- there's a real cost when we > have platform changes to make, and 10 m68k copies are needed > instead of 1. we've done some of this over time (for not > just m68k) but there's quite a lot of left here.. > > thanks. > > > .mrg.
re: CVS commit: src/sys/arch/news68k/conf
> I was changing news68k specific code, thus wasn't treating them as > common. But I understand the point. there's a *LOT* of m68k code that is copied into all the ports that is almost identical, and should really be shared, but it not, and changes like can make this harder to share. ie, while it might appear news68k specific, ideally most of it would end up in arch/m68k instead. it would really be far better for that merge, than to worry about obscure compile options -- there's a real cost when we have platform changes to make, and 10 m68k copies are needed instead of 1. we've done some of this over time (for not just m68k) but there's quite a lot of left here.. thanks. .mrg.
Re: CVS commit: src/sys/arch/news68k/conf
On Sun, Oct 8, 2023 at 6:56 AM Izumi Tsutsui wrote:
>
> > In this case maybe I should remove all FPSP references (vectors.S,
> > locore.S, Makefile.news68k (MD_LIBS={FPSP})?
>
> IMO we don't have to keep strict consistencies or buildabilities of
> options but rather should consider readabilities and maintainabilities.
>
> - options FPSP in a config file is not necessary for users on news68k
> (unless some users build own 040/060 upgrade mod like x68k)
Yes, that's understandable and true. However, if someone would have a
mod, he would need to understand why FPSP build fails in the first
place.
I just wanted to avoid confusion, that code has ifdef blocks, but
there's no way to build it.
> - #ifdef FPSP (and other m68k specific options) blocks in common
> sources might help to check diffs from other m68k ports
I was changing news68k specific code, thus wasn't treating them as
common. But I understand the point.
I can return FPSP block in vectors.s, if that helps with readability
and maintainability.
However, those copy pasted common files usually diverge between ports
(from what I've seen),
makes it difficult to understand what is still common and what is the
"latest" code at times (likely not in this case).
> - In the perfect world, we should have a common m68k/locore.s etc.
>and move port specific blocks into locore_machdep.s like mips,
>but m68k CPUs are too flexible and all m68k ports have too many
>historical difficulties to refactor them
I admit I went a bit impatient this time without waiting for the
proper answer. I am OK to settle with the best option in the context,
either revert everything to original state, keep partial changes or
leave current state. Sorry for this.
>
> I don't mind your changes in this case, but it's appreciated
> to ask design considerations before changes, as you did for mmeye.
>
> Thanks,
> ---
> Izumi Tsutsui
Re: CVS commit: src/sys/arch/news68k/conf
> In this case maybe I should remove all FPSP references (vectors.S,
> locore.S, Makefile.news68k (MD_LIBS={FPSP})?
IMO we don't have to keep strict consistencies or buildabilities of
options but rather should consider readabilities and maintainabilities.
- options FPSP in a config file is not necessary for users on news68k
(unless some users build own 040/060 upgrade mod like x68k)
- #ifdef FPSP (and other m68k specific options) blocks in common
sources might help to check diffs from other m68k ports
- In the perfect world, we should have a common m68k/locore.s etc.
and move port specific blocks into locore_machdep.s like mips,
but m68k CPUs are too flexible and all m68k ports have too many
historical difficulties to refactor them
I don't mind your changes in this case, but it's appreciated
to ask design considerations before changes, as you did for mmeye.
Thanks,
---
Izumi Tsutsui
Re: CVS commit: src/sys
On Thu, Oct 05, 2023 at 12:15:23PM +0200, Martin Husemann wrote: > On Thu, Oct 05, 2023 at 09:59:49AM +, Andrew Doran wrote: > > Yes that makes sense and is what I plan to do after work today if nobody > > beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel, > > IMO. > > Hey, this is a tiny landisk kernel, do not bloat it :-) And I thought I had more of a reputation for tearing things out of the OS.. > Unfortunately it is not trivial to make that zeroing happen in the > macros that we have now (gcc is pretty picky with warnings, would love > to have c++ templates here). I rearranged things so it shouldn't be necessary.. At least a pmax kernel builds for me now. Sorry about the interruption. Andrew
Re: CVS commit: src/sys
On Thu, Oct 05, 2023 at 09:59:49AM +, Andrew Doran wrote: > Yes that makes sense and is what I plan to do after work today if nobody > beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel, > IMO. Hey, this is a tiny landisk kernel, do not bloat it :-) Unfortunately it is not trivial to make that zeroing happen in the macros that we have now (gcc is pretty picky with warnings, would love to have c++ templates here). Martin
Re: CVS commit: src/sys
Martin, On Thu, Oct 05, 2023 at 11:42:03AM +0200, Martin Husemann wrote: > On Thu, Oct 05, 2023 at 11:36:23AM +0200, Martin Husemann wrote: > > No, I was confused by the #ifdef maze - it breaks the build for > > non-MULTIPROCESSOR kernels only, and I am not actually sure what "use" > > gcc sees for the "nlocks" variable at all in that case. > > Scratch that too, I'll get coffee. > > Andrew, should we make the non-MULTIPROCESSOR variant of > > KERNEL_UNLOCK(all, lwp, ptr) > > set *(ptr) = 0 ? Yes that makes sense and is what I plan to do after work today if nobody beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel, IMO. Andrew
