Re: Can version bump up to 9.99.100?
On Fri, Sep 16, 2022 at 07:00:23PM +0700, Robert Elz wrote: > That is, except for in pkgsrc, which is why I still > have a (very mild) concern about that one - it actually compares the > version numbers using its (until it gets changed) "Dewey" comparison > routines, and for those, 9.99.100 is uncharted territory. No, it's not, pkgsrc-Dewey is well defined on arbitrarily large numbers. In fact, that's in some sense the whole point of it relative to using fixed-width fields. The only problem that might arise is that someone might have used a glob pattern of the form NetBSD-9.99.[7-9]* that will unexpectedly stop working. These would appear because make doesn't know how to do pkgsrc-Dewey computations internally. While it's possible that some of these may exist, it's unlikely that there are many of them or that they appear anywhere especially important. (Patterns of the form NetBSD-[6-9]* do appear and people have been hunting those down lately.) -- David A. Holland dholl...@netbsd.org
Re: Can version bump up to 9.99.100?
Date:Fri, 16 Sep 2022 12:59:24 -0400 From:"David H. Gutteridge" Message-ID: | So there will be information loss there, at minimum. Whether that ends | up being significant at some point, I guess we can't say. I would hope not. That is, I am assuming (but don't know pkgsrc well enough to be sure) that OPSYS_VERSION gets used for some kind of feature test. That's OK (not the ideal method - but sometimes it is the only practical one) for major, or even minor version comparisons. It isn't for the 3rd field (xx) in N.99.xx for NetBSD. That field is not changed for feature additions, so some N.99.xx may have a particular feature, and others not, but is changed for internal ABI alterations (which don't necessarily affect what is visible by applications in any way at all). Note also that this value is never changed (in the NetBSD N.99.xx case) because of changes that occur to anything outside the kernel - so it can never safely be used to test what version of some application or library function might be installed. Never. If pkgsrc (or pkgsrc packages) are using this sensibly, then limiting OPSYS_VERSION at 09 for all future __NetBSD_Version__ values 9.99.x where x >= 100 should be safe, as nothing should ever care about those final 2 digits. That's "if". kre ps: the issue I was concerned about more would occur when the kernel version info gets embedded in a package version, and other similar things.
Re: Can version bump up to 9.99.100?
On Fri, 16 Sep 2022 at 19:00:23 +0700, Robert Elz wrote:
[...] That is, except for in pkgsrc, which is why I still
have a (very mild) concern about that one - it actually compares the
version numbers using its (until it gets changed) "Dewey" comparison
routines, and for those, 9.99.100 is uncharted territory.
One wrinkle is that the current definition of OPSYS_VERSION (in
pkgsrc/mk/bsd.prefs.mk) does this (wrapped for formatting):
_OPSYS_VERSION_CMD= ${UNAME} -r | \
awk -F. '{major=int($$1); minor=int($$2);
if (minor>=100) minor=99; patch=int($$3);
if (patch>=100) patch=99; printf "%02d%02d%02d",
major, minor, patch}'
So there will be information loss there, at minimum. Whether that ends
up being significant at some point, I guess we can't say. Someone could
always re-implement something different for NetBSD (meaning all the
existing NetBSD-specific uses of OPSYS_VERSION would be adjusted).
(There are 135 instances of OPSYS_VERSION in pkgsrc presently. I don't
know offhand how many are NetBSD-specific, that's harder to count, but
it's a significant subset, I believe.)
Regards,
Dave
Re: Can version bump up to 9.99.100?
I test module loading with just bumped up src. After build.sh modules && build.sh installmodules, that works fine. # uname -r 9.99.100 # ls -dl /stand/amd64/9.99.100/modules/tprof* drwxr-xr-x 2 root wheel 512 Sep 16 17:45 /stand/amd64/9.99.100/modules/tprof drwxr-xr-x 2 root wheel 512 Sep 16 17:46 /stand/amd64/9.99.100/modules/tprof_x86 # modstat | grep tprof # modload tprof_x86 # echo $? 0 # modstat | grep tprof tprof driver filesys a14957 - tprof_x86 driver filesys -02010 tprof Excellent - looks good. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Can version bump up to 9.99.100?
Date:Thu, 15 Sep 2022 23:46:45 -0700 (PDT) From:Paul Goyette Message-ID: | The human-oriented version is used as part of the path to modules | directory. Need to make sure that the modules set is properly | populated, That much I had tested. | and that module loads find them in the directory. but that I did not - but Kengo NAKAHARA now has, so that's all good, I really couldn't see how there would be a problem here (but testing it was good) as it is all just strings (the only comparisons are of the binary blobs). That is, except for in pkgsrc, which is why I still have a (very mild) concern about that one - it actually compares the version numbers using its (until it gets changed) "Dewey" comparison routines, and for those, 9.99.100 is uncharted territory. kre
Re: Can version bump up to 9.99.100?
Hi, Thank you for your comment. On 2022/09/16 15:46, Paul Goyette wrote: On Fri, 16 Sep 2022, Robert Elz wrote: Date: Fri, 16 Sep 2022 11:10:30 +0900 From: Kengo NAKAHARA Message-ID: <90c3c46e-6668-9644-70c3-0eab2cf1c...@iij.ad.jp> | Hmm, I will test kernel module building before commit. Sorry, I wasn't clear - I build everything (modules included) - I just never actually load any modules, so I haven't tested them (my kernels have the MODULAR option disabled). I cannot imagine an issue, as internally everything just uses __NetBSD_Version__ as a 32 bit (ordered) blob - the breakdown into 9.99.100 type strings is just for us humans (and pkgsrc). Not entirely true. The human-oriented version is used as part of the path to modules directory. Need to make sure that the modules set is properly populated, and that module loads find them in the directory. I test module loading with just bumped up src. After build.sh modules && build.sh installmodules, that works fine. # uname -r 9.99.100 # ls -dl /stand/amd64/9.99.100/modules/tprof* drwxr-xr-x 2 root wheel 512 Sep 16 17:45 /stand/amd64/9.99.100/modules/tprof drwxr-xr-x 2 root wheel 512 Sep 16 17:46 /stand/amd64/9.99.100/modules/tprof_x86 # modstat | grep tprof # modload tprof_x86 # echo $? 0 # modstat | grep tprof tprof driver filesys a14957 - tprof_x86 driver filesys -02010 tprof Thanks, -- // Internet Initiative Japan Inc. Device Engineering Section, Product Division, Technology Unit Kengo NAKAHARA
Re: Can version bump up to 9.99.100?
On Fri, 16 Sep 2022, Robert Elz wrote: Date:Fri, 16 Sep 2022 11:10:30 +0900 From:Kengo NAKAHARA Message-ID: <90c3c46e-6668-9644-70c3-0eab2cf1c...@iij.ad.jp> | Hmm, I will test kernel module building before commit. Sorry, I wasn't clear - I build everything (modules included) - I just never actually load any modules, so I haven't tested them (my kernels have the MODULAR option disabled). I cannot imagine an issue, as internally everything just uses __NetBSD_Version__ as a 32 bit (ordered) blob - the breakdown into 9.99.100 type strings is just for us humans (and pkgsrc). Not entirely true. The human-oriented version is used as part of the path to modules directory. Need to make sure that the modules set is properly populated, and that module loads find them in the directory. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Can version bump up to 9.99.100?
Date:Fri, 16 Sep 2022 11:10:30 +0900 From:Kengo NAKAHARA Message-ID: <90c3c46e-6668-9644-70c3-0eab2cf1c...@iij.ad.jp> | Hmm, I will test kernel module building before commit. Sorry, I wasn't clear - I build everything (modules included) - I just never actually load any modules, so I haven't tested them (my kernels have the MODULAR option disabled). I cannot imagine an issue, as internally everything just uses __NetBSD_Version__ as a 32 bit (ordered) blob - the breakdown into 9.99.100 type strings is just for us humans (and pkgsrc). kre
