On Wed, 27 Aug 2025 11:12:42 -0700 Chris <bsd-li...@bsdforge.com> wrote:
> On 2025-08-27 09:13, Warner Losh wrote: > > On Wed, Aug 27, 2025 at 10:00 AM Mel P. <list_free...@bluerosetech.com> > > wrote: > > > >> On 2025-08-27 7:34, Warner Losh wrote: > >> > On Wed, Aug 27, 2025 at 8:12 AM Russell Adams > >> > <russell.ad...@adamssystems.nl <mailto:russell.ad...@adamssystems.nl>> > >> > wrote: > >> > This was exactly my experience in the forum post. Multiple versions > >> > had the same "Revision" tag, and there is no way to crossreference > >> > with a specific Freebsd version. > >> > > >> > > >> > We used to encode the date the loader was built. Reproducible builds > >> > stopped that. > >> > > >> > The Revision tag really is what boot protocol is supported. That > >> > protocol changes very rarely. > >> 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. > > > > 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. > > > > I'm on the fence about git hashes. I generally don't like it. But we do it > > for the kernel, and it might be appropriate here. Though it introduces a > > dependency on the git tree and the 'n' number is highly dependent on how > > the tree was cloned. > I'd lobby against git related stuff. We started with rcs, then cvs, then svn, > then git. We don't really believe we'll be using git forever more, do we? :) Even though I've mentioned about git hash, I honestly don't like git hash. Serial numbers for commits on the single repo like in cvs and svn is much easier to track (at least for me). Yes, there's n-number on kernel (generated into /usr/obj/usr/src/amd64.amd64/sys/TEST15/vers.c using git functionality). But I suspect it can be mis-match between users having issue and developer who attempt to fix it, as human make mistakes. For example, it any single side of them missingly committed something to any of official branch (i.e., stable/14) in the person's local repo instead of the person's local branch (i.e., stable14/local), isn't the n-number differ? This is why I've once requested separate official database tying git hash and serial number per-repository and embed the number in commit emails in dev-commit-* ML. (At the moment, current n-number is implemented instead.) > > > > > Warner > > -- > The internet is not a place. -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
