Page MenuHomeFreeBSD

Allow the bundled zstd to use utimensat
Needs RevisionPublic

Authored by asomers on Mar 12 2024, 7:31 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, May 9, 2:05 PM
Unknown Object (File)
Tue, May 7, 1:48 PM
Unknown Object (File)
Sat, Apr 27, 8:46 AM
Unknown Object (File)
Fri, Apr 26, 5:00 AM
Unknown Object (File)
Sat, Apr 20, 11:26 PM
Unknown Object (File)
Apr 7 2024, 12:28 PM
Unknown Object (File)
Apr 5 2024, 1:15 PM
Unknown Object (File)
Mar 13 2024, 8:46 PM
Subscribers

Details

Reviewers
allanjude
imp
Summary

Without this change, it will use utime instead, dropping the subsecond
portion of the timestamp.

See upstream discussion: https://github.com/facebook/zstd/pull/3952

MFC after: 2 weeks
Sponsored by: Axcient

Diff Detail

Repository
rG FreeBSD src repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 56554
Build 53442: arc lint + arc unit

Event Timeline

imp requested changes to this revision.Mar 12 2024, 7:58 PM

This isn't quite right. We also should change sys/sys/unistd.h since it only defines 200112 compliance, when we're effectively 200809 compliant.
We should likely just move the BSD defines down to the highlighted #if, but we'd also need to make the sys/sys/unitstd.h change. I'd recommend that for upstream, then it automatiocally starts working.

We can bump it , do an exp run and commit it. no doubt there's workarounds for our tardiness in bumping this.

sys/contrib/zstd/programs/platform.h
78

this looks wrong. It should only drop FreeBSD from this, not all the BSDs. We all have somewhat different implementations in this area and it kinda matters.

93

this really should be where the missing #ifdefs are added, since all the BSD support _POSIX_VERSION via unistd.h in some way or another... but see below.

101

The problem is here... We only define that we have 200112 compliance, not 200809 compliance (which we have).

This revision now requires changes to proceed.Mar 12 2024, 7:58 PM

An exp-run is what you suggested when I first raised the issue on freebsd-hackers last September. However, I don't know how to do an exp-run. Are you volunteering?

sys/contrib/zstd/programs/platform.h
78

Actually, upstream is dropping all of the BSDs from this line. That's why I did it too.

An exp-run is what you suggested when I first raised the issue on freebsd-hackers last September. However, I don't know how to do an exp-run. Are you volunteering?

It's in the committer's guide...

Create a buzilla
Upload the diff
Tick on Show Advanced Fields
Change 'exp run' box to '?'

22.8.6. How can an experimental test build of the ports tree (exp-run) be requested?

So digging into this a bit more... I bumped the POSIX_VERSION in FreeBSD. This code seemed to compile great when I did that after I moved the BSDs to the #if I highlighted.

However, OpenSSL needs a small tweak. POSIX_VERSION 200809L dropped makecontext, et al, from the standard in Issue 7 (2008 version), and OpenSSL has no fallback for that situation, except to make an exception for GLIBC... So I added an exception for FreeBSD as well, and submitted that pull request. Now I have to fix at least two ports (openssl3 and openssl111), and fight that battle.... At least I have someone lined up to help me there.

So there's a complication to my suggestion, I'll let you know when vvd@ and I have looked at the fallout. I hate kludging things like this pull request, though, I'm spending way more time on this than I thought I'd need to.

In D44320#1014666, @imp wrote:

So digging into this a bit more... I bumped the POSIX_VERSION in FreeBSD. This code seemed to compile great when I did that after I moved the BSDs to the #if I highlighted.

However, OpenSSL needs a small tweak. POSIX_VERSION 200809L dropped makecontext, et al, from the standard in Issue 7 (2008 version), and OpenSSL has no fallback for that situation, except to make an exception for GLIBC... So I added an exception for FreeBSD as well, and submitted that pull request. Now I have to fix at least two ports (openssl3 and openssl111), and fight that battle.... At least I have someone lined up to help me there.

So there's a complication to my suggestion, I'll let you know when vvd@ and I have looked at the fallout. I hate kludging things like this pull request, though, I'm spending way more time on this than I thought I'd need to.

Thanks for working on that . I agree that it would definitely be a better solution that what I proposed. Is there anything that I can do to help?