re: 9.99.100 fallout: file(1)
> However, I wonder why this kind of info is embedded in ELF files, what > point does that have? Maybe it would be better to have them just say > x.99 (and forget the kernel ABI bump number) ? i would rather keep the info. i use it as a quick check of whether i reinstalled recently or not. "file /bin/sh". .mrg.
Re: 9.99.100 fallout: file(1)
k...@munnari.oz.au (Robert Elz) writes:
>The way you have it coded, I suspect that 9.1 binaries will appear to
>be 9.1.0 instead (the ver_patch data is always appended for ver_maj >= 9).
True. Here is a patch that ignores a zero patch level.
Index: external/bsd/file/dist/src/readelf.c
===
RCS file: /cvsroot/src/external/bsd/file/dist/src/readelf.c,v
retrieving revision 1.25
diff -p -u -r1.25 readelf.c
--- external/bsd/file/dist/src/readelf.c9 Apr 2021 19:11:42 -
1.25
+++ external/bsd/file/dist/src/readelf.c21 Sep 2022 23:17:49 -
@@ -456,7 +456,13 @@ do_note_netbsd_version(struct magic_set
if (file_printf(ms, " %u.%u", ver_maj, ver_min) == -1)
return -1;
- if (ver_rel == 0 && ver_patch != 0) {
+ if (ver_maj >= 9) {
+ ver_patch += 100 * ver_rel;
+ if (ver_patch != 0) {
+ if (file_printf(ms, ".%u", ver_patch) == -1)
+ return -1;
+ }
+ } else if (ver_rel == 0 && ver_patch != 0) {
if (file_printf(ms, ".%u", ver_patch) == -1)
return -1;
} else if (ver_rel != 0) {
>However, I wonder why this kind of info is embedded in ELF files, what
>point does that have? Maybe it would be better to have them just say
>x.99 (and forget the kernel ABI bump number) ?
The note has little value, best it can do is identify from which
release the binary came, in case you have a mixed installation. And
then the full version number is required.
Re: 9.99.100 fallout: file(1)
Date:Wed, 21 Sep 2022 19:33:47 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| - if (ver_rel == 0 && ver_patch != 0) {
| + if (ver_maj >= 9) {
I'd suggest instead
if (ver_min == 99) {
While this issue never happened with earlier NetBSDs there's no
real reason to exclude them from the possibility that it might have.
On the other hand, there's never been a version since we introduced the
.99 concept (NetBSD 2 going on to 3?) where x.99 had anything other than
a single decimal suffix. And we never had, and I don't think anyone
expects that we ever will have, a N.9x version of NetBSD where x != 9).
That is, ver_min never has been, and never will be, 99, other than to
indicate "on the way to ver_maj + 1".
The way you have it coded, I suspect that 9.1 binaries will appear to
be 9.1.0 instead (the ver_patch data is always appended for ver_maj >= 9).
However, I wonder why this kind of info is embedded in ELF files, what
point does that have? Maybe it would be better to have them just say
x.99 (and forget the kernel ABI bump number) ?
kre
Re: 9.99.100 fallout: file(1)
campbell+netbsd-tech-k...@mumble.net (Taylor R Campbell) writes:
>We appear to have revived the old alphanumeric versioning scheme,
>according to file(1)! Someone needs to teach file(1) that this is
>9.99.100, not 9.99A(.0).
Index: external/bsd/file/dist/src/readelf.c
===
RCS file: /cvsroot/src/external/bsd/file/dist/src/readelf.c,v
retrieving revision 1.25
diff -p -u -r1.25 readelf.c
--- external/bsd/file/dist/src/readelf.c9 Apr 2021 19:11:42 -
1.25
+++ external/bsd/file/dist/src/readelf.c21 Sep 2022 19:32:32 -
@@ -456,7 +456,11 @@ do_note_netbsd_version(struct magic_set
if (file_printf(ms, " %u.%u", ver_maj, ver_min) == -1)
return -1;
- if (ver_rel == 0 && ver_patch != 0) {
+ if (ver_maj >= 9) {
+ ver_patch += 100 * ver_rel;
+ if (file_printf(ms, ".%u", ver_patch) == -1)
+ return -1;
+ } else if (ver_rel == 0 && ver_patch != 0) {
if (file_printf(ms, ".%u", ver_patch) == -1)
return -1;
} else if (ver_rel != 0) {
% file /bin/ls
/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /libexec/ld.elf_so, for NetBSD 9.99.100, not stripped
Re: 9.99.100 fallout: bootloader and modules
> On Sep 21, 2022, at 5:00 AM, Johnny Billquist wrote:
>
> Searching for uses of netbsd_version, there is some more broken logic in a
> few places, following similar patterns or assumptions.
>
> Like in /usr/src/sys/arch/i386/stand/lib/exec.c:
>
>if (netbsd_version / 100 % 100 == 99) {
>/* -current */
>snprintf(buf, bufsize,
>"/stand/%s/%d.%d.%d/modules", machine,
>netbsd_version / 1,
>netbsd_version / 100 % 100,
>netbsd_version / 100 % 100);
>} else if (netbsd_version != 0) {
>/* release */
>snprintf(buf, bufsize,
>"/stand/%s/%d.%d/modules", machine,
>netbsd_version / 1,
>netbsd_version / 100 % 100);
>}
>
>
> So just changing the modulo in the place you were suggesting isn't enough. :-P
Obviously we need a function in libsa or libkern for this.
-- thorpej
Re: 9.99.100 fallout: bootloader and modules
Searching for uses of netbsd_version, there is some more broken logic in
a few places, following similar patterns or assumptions.
Like in /usr/src/sys/arch/i386/stand/lib/exec.c:
if (netbsd_version / 100 % 100 == 99) {
/* -current */
snprintf(buf, bufsize,
"/stand/%s/%d.%d.%d/modules", machine,
netbsd_version / 1,
netbsd_version / 100 % 100,
netbsd_version / 100 % 100);
} else if (netbsd_version != 0) {
/* release */
snprintf(buf, bufsize,
"/stand/%s/%d.%d/modules", machine,
netbsd_version / 1,
netbsd_version / 100 % 100);
}
So just changing the modulo in the place you were suggesting isn't
enough. :-P
Johnny
On 2022-09-21 13:47, Taylor R Campbell wrote:
The x86 bootloader, and the MI efiboot, are unable to find modules
when the kernel version is 9.99.100 -- they try
/stand/$ARCH/9.99.0/modules instead, because of this logic:
/* sys/arch/i386/stand/lib/exec.c */
snprintf(buf, bufsize,
"/stand/%s/%d.%d.%d/modules", machine,
netbsd_version / 1,
netbsd_version / 100 % 100,
netbsd_version / 100 % 100);/* XXX */
/* sys/stand/efiboot/module.c */
const u_int vmajor = netbsd_version / 1;
const u_int vminor = netbsd_version / 100 % 100;
const u_int vpatch = netbsd_version / 100 % 100;/* XXX */
I will try the attached patch to do `% 1' instead of `% 100' on
the lines marked XXX. Likely other bootloaders will need to be
adjusted to handle this. Loading modules from the bootloader in a
=9.99.100 kernel will require updating the bootloader.
(After boot, module loading works fine because the kernel's module
loader uses the `osrelease' string instead of doing arithmetic on
__NetBSD_Version__.)
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
9.99.100 fallout: file(1)
$ file ./netbsd ./netbsd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for NetBSD 9.99A, not stripped We appear to have revived the old alphanumeric versioning scheme, according to file(1)! Someone needs to teach file(1) that this is 9.99.100, not 9.99A(.0).
9.99.100 fallout: bootloader and modules
The x86 bootloader, and the MI efiboot, are unable to find modules
when the kernel version is 9.99.100 -- they try
/stand/$ARCH/9.99.0/modules instead, because of this logic:
/* sys/arch/i386/stand/lib/exec.c */
snprintf(buf, bufsize,
"/stand/%s/%d.%d.%d/modules", machine,
netbsd_version / 1,
netbsd_version / 100 % 100,
netbsd_version / 100 % 100);/* XXX */
/* sys/stand/efiboot/module.c */
const u_int vmajor = netbsd_version / 1;
const u_int vminor = netbsd_version / 100 % 100;
const u_int vpatch = netbsd_version / 100 % 100;/* XXX */
I will try the attached patch to do `% 1' instead of `% 100' on
the lines marked XXX. Likely other bootloaders will need to be
adjusted to handle this. Loading modules from the bootloader in a
>=9.99.100 kernel will require updating the bootloader.
(After boot, module loading works fine because the kernel's module
loader uses the `osrelease' string instead of doing arithmetic on
__NetBSD_Version__.)
>From 40c19f9c5a6dc16cbc869f88bfaca70b064d314c Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Wed, 21 Sep 2022 11:42:25 +
Subject: [PATCH 1/2] i386/stand: Handle 9.99.100 by taking four, not two,
digits.
We haven't used the revision part of __NetBSD_Version__ = MMmmrrpp00
in almos two decades so we're apparently reclaiming it as MMmm00.
---
sys/arch/i386/stand/lib/exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys/arch/i386/stand/lib/exec.c b/sys/arch/i386/stand/lib/exec.c
index 89acb0536fea..6a7ee70cf179 100644
--- a/sys/arch/i386/stand/lib/exec.c
+++ b/sys/arch/i386/stand/lib/exec.c
@@ -684,7 +684,7 @@ module_base_path(char *buf, size_t bufsize, const char
*kernel_path)
"/stand/%s/%d.%d.%d/modules", machine,
netbsd_version / 1,
netbsd_version / 100 % 100,
- netbsd_version / 100 % 100);
+ netbsd_version / 100 % 1);
} else if (netbsd_version != 0) {
/* release */
snprintf(buf, bufsize,
>From 4de556562376b9a50f9f70984a937451f46c5773 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Wed, 21 Sep 2022 11:45:04 +
Subject: [PATCH 2/2] efiboot: Handle 9.99.100 by taking four, not two, digits.
We haven't used the revision part of __NetBSD_Version__ = MMmmrrpp00
in almos two decades so we're apparently reclaiming it as MMmm00.
---
sys/stand/efiboot/module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys/stand/efiboot/module.c b/sys/stand/efiboot/module.c
index 48023ccb0ca2..918f5345ce54 100644
--- a/sys/stand/efiboot/module.c
+++ b/sys/stand/efiboot/module.c
@@ -62,7 +62,7 @@ module_set_prefix(const char *kernel_path)
#else
const u_int vmajor = netbsd_version / 1;
const u_int vminor = netbsd_version / 100 % 100;
- const u_int vpatch = netbsd_version / 100 % 100;
+ const u_int vpatch = netbsd_version / 100 % 1;
if (vminor == 99) {
snprintf(module_prefix, sizeof(module_prefix),
