Re: Which version is BOOTX64.efi?

On 2025-08-29 06:24, Tomoaki AOKI wrote:
> On Wed, 27 Aug 2025 11:12:42 -0700
> Chris <bsd-lists@bsdforge.com> wrote:
> 
>> On 2025-08-27 09:13, Warner Losh wrote:
>> > On Wed, Aug 27, 2025 at 10:00 AM Mel P. <list_freebsd@bluerosetech.com>
>> > wrote:
>> >
>> >> On 2025-08-27 7:34, Warner Losh wrote:
>> >> > On Wed, Aug 27, 2025 at 8:12 AM Russell Adams
>> >> > <Russell.Adams@adamssystems.nl <mailto:Russell.Adams@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?

> 
> 
>> 
>> >
>> > Warner
>>