On Fri, 29 Aug 2025 07:49:49 -0600 Warner Losh <i...@bsdimp.com> wrote:
> On Fri, Aug 29, 2025, 7:12 AM Tomoaki AOKI <junch...@dec.sakura.ne.jp> > wrote: > > > On Wed, 27 Aug 2025 10:52:30 -0700 > > "Mel P." <list_free...@bluerosetech.com> wrote: > > > > > On 2025-08-27 9:13, Warner Losh wrote: > > > > On Wed, Aug 27, 2025 at 10:00 AM Mel P. <list_free...@bluerosetech.com > > > > <mailto:list_free...@bluerosetech.com>> wrote: > > > > > > > > If loaders had the version and patch level hardcoded into them it > > > > during > > > > the build like how that information is hardcoded into > > freebsd-version, > > > > would that be a reproducible build? If so, can EFI loaders with > > ZFS > > > > support also have the OpenZFS version? For example: > > > > > > > > FreeBSD/amd64 EFI loader, Revision 1.1, 13.5-RELEASE, > > OpenZFS-2.1.15 > > > > > > > > Those two version numbers would be immensely helpful when moving > > disks > > > > or verifying upgrades. > > > > > > > > > > > > Yea, that's not going to happen. The loader is independent of the > > > > release, in many ways, 13.5-RELEASE comes from the kernel, and this > > > > would introduce a coupling between the two. We generally don't have > > the > > > > OpenZFS version available. We don't sync to OpenZFS releases, > > > > necessarily. Also, the boot loader only makes limited use of the > > OpenZFS > > > > code, so its version wouldn't necessarily help you. There's often a > > lag > > > > between OpenZFS code hitting the tree and the boot loader > > understanding > > > > new items introduced by that import. > > > > > > This is very good to know, thank you. > > > > > > > We can report the _FreeBSD_version for the tree we build in, though. > > And > > > > that will give you information. We don't currently bump it, though, > > when > > > > we add ZFS features to the whitelist of enabled features, but could. > > > > This would make it still reproducible. > > > > > > __FreeBSD_version would be just as helpful. > > > > > > That feature whitelist is exactly the information needed when figuring > > > out if a given loader can boot a given pool and fs. Would it be > > > possible to include that in the loader in a way that strings or some > > > other utility can find it? > > > > Unfortunately, __FreeBSD_version is NOT promised to be bumped everytime > > loader/bootcode receive new ZFS read-incompatible features support. > > > > Two points: it gets bumped fairly often anyway, so there only a few commits > between the change and a zfs change. This is also true, btw, for the change > in the tree and the bumps. There's often a lag. So it's always going to be > bother pretty good on the long scane, and imprecise on the short. It's also > the same everywhere no matter what. > > This is why I previously commented with git hash and/or n number. > > > > This is harder and introduces a git dependency to the loader process. The > kernel has this, true. And hg, svn, gitup and a few others. It's a mess > that I'd rather not have since the loader is built a dozen times, not once > like the kernel, and any slowdown when one of the above scms misbehaves is > greater. > > Warner Yeah, precisely determining what read-incompatible features is/are enabled (whitelisted) is the key point for the bootcodes / loaders. Using date/time, ancient method was (IIRC) the date/time the bootcodes / loaders are "built", NOT "committed to master repo". Obtaining the actually wanted date / time needs git functionality in current form, thus, heavy-weighted for bootcodes / loaders. If there's a database (simple KVS storing serial and hash would be enough) is maintained officially (quite wild guess, but all commits are emailed to corresponding dev-commits-* MLs, automatically storing hash into the DB would be "technically" possible). And if (not sure it's possible or not) some kind of "trigger" to pull it and record in what serial the source code is at when pulling and/or checking out src tree (would be nice for ports tree, too) into special file (i.e., /usr/obj/vcsnum, which is something like /usr/obj/usr/src/amd64.amd64/sys/TEST15/version), it would be trivial enough to use it on building anything in /usr/src/stand. Downsides would be additional thing to maintain is introduced, and it could be become 2 when switching VCS (like svn to git) while in transition periods. But it wouldn't be so often. *Maybe making DB in 3 fields to add VCS into account could be a choice, but as serial numbers needs to be equal for commits only differs in used VCS, which makes DB insane, so I dislike it. And how to make triggers work for non-official mirrors like GitLab and Codeberg (or even official GitHub mirror). Maybe (not sure how to implement, though) some wrapper script to git would be needed to allow something like got and gitup to be used. Sorry, just an idea. > -- > > Tomoaki AOKI <junch...@dec.sakura.ne.jp> -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
