Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add ptp_clock_caps #4128

Merged
merged 1 commit into from
Nov 21, 2024
Merged

add ptp_clock_caps #4128

merged 1 commit into from
Nov 21, 2024

Conversation

folkertdev
Copy link
Contributor

@folkertdev folkertdev commented Nov 20, 2024

Description

The final missing pieces of #3865

Sources

Checklist

  • Relevant tests in libc-test/semver have been updated
  • No placeholder or unstable values like *LAST or *MAX are
    included (see #3131)
  • Tested locally (cd libc-test && cargo test --target mytarget);
    especially relevant for platforms that may not be checked in CI

r? @tgross35

@@ -1206,6 +1206,81 @@ s! {
}
}

cfg_if! {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so yeah, this looks like the best I can do...

Defining a PTP_CLOCK_CAPS_RSV_LEN const just does not seem to work. not with cfg_if, a vanilly block with an if expression, defining a const fn and calling that: they all run into unreachable code in garando.

Next it tusrns out that loongarch is weird and special (or just has a later version maybe?), so that further complicates the situation.

It looks like I can bring it down to three branches by just making the conditionals more complex (that almost adds as many lines as it saves...) Any other ideas?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do all these definitions even come from? I don't see it in glibc or musl source so I assume it should be uapi source, but I only see the one definition with no conditions https://github.com/torvalds/linux/blob/43fb83c17ba2d63dfb798f0be7453ed55ca3f9c2/include/uapi/linux/ptp_clock.h#L94-L107

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, all the special cases are older versions where they don't have new fields and have more elements in that rsv array. So it might be possible to just have the latest version and just ignore all targets/CI configurations where that does not (yet) work?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh all of this was just accounting for what we happen to test in CI rather than actual sources? Why didn't you just say so :) we should definitely only implement the latest and skip tests on platforms where we can explain the failure.

If this explains the platform-specific config for the other PTP structs (I think there was something for sparc), mind putting up a PR to drop that as well?

I suggested a few changes here but think this should mostly be good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the rest of the ptp structs are clean (no cfg's or anything like that). For the ioctl const functions there is some powerpc/sparc/mips-specific logic, but that really is because they define constants with different values. There are links to those values there so I think it's all good now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM, I must have been thinking of something else. Thanks for the followup.

@folkertdev folkertdev force-pushed the ptp-clock-caps branch 2 times, most recently from 72b85fb to 1d29316 Compare November 21, 2024 18:35
src/unix/linux_like/linux/mod.rs Show resolved Hide resolved
libc-test/build.rs Outdated Show resolved Hide resolved
libc-test/build.rs Outdated Show resolved Hide resolved
@tgross35 tgross35 marked this pull request as ready for review November 21, 2024 19:01
@tgross35 tgross35 enabled auto-merge November 21, 2024 19:01
@tgross35 tgross35 added the stable-nominated This PR should be considered for cherry-pick to libc's stable release branch label Nov 21, 2024
@tgross35 tgross35 added this pull request to the merge queue Nov 21, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to no response for status checks Nov 21, 2024
@tgross35 tgross35 added this pull request to the merge queue Nov 21, 2024
Merged via the queue into rust-lang:main with commit 01c7a63 Nov 21, 2024
45 checks passed
@bors bors mentioned this pull request Nov 21, 2024
3 tasks
@folkertdev
Copy link
Contributor Author

thanks for the help here @tgross35, that was a journey!

tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Nov 25, 2024
(backport <rust-lang#4128>)
(cherry picked from commit 38318cd)
This was referenced Nov 25, 2024
tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Nov 25, 2024
(backport <rust-lang#4128>)
(cherry picked from commit 38318cd)
tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Nov 25, 2024
(backport <rust-lang#4128>)
(cherry picked from commit 38318cd)
tgross35 pushed a commit to tgross35/rust-libc that referenced this pull request Nov 25, 2024
(backport <rust-lang#4128>)
(cherry picked from commit 38318cd)
@tgross35 tgross35 added stable-applied This PR has been cherry-picked to libc's stable release branch and removed stable-nominated This PR should be considered for cherry-pick to libc's stable release branch labels Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-linux O-unix S-waiting-on-review stable-applied This PR has been cherry-picked to libc's stable release branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants