On Sat, 30 Aug 2025 11:28:48 -0700 Chris <bsd-li...@bsdforge.com> wrote:
> On 2025-08-29 06:24, Tomoaki AOKI wrote: > > 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.) > Wouldn't something as simple as date(1) or epoch(9) be good candidates? Isn't simple usage of data(1) and/or epoch(9) make "built time" to be used? I think what's important is in which commit the specific bootcode / loader is/are built from, thus, commented to Warner's reply. https://lists.freebsd.org/archives/freebsd-stable/2025-August/003088.html > >> > Warner > >> -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
