-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 devstat items #2565
Add devstat items #2565
Conversation
r? @JohnTitor (rust-highfive has picked a reviewer for you, use r? to override) |
pub tk_nin: ::c_long, | ||
pub tk_nout: ::c_long, | ||
pub dinfo: *mut devinfo, | ||
pub snap_time: ::c_double, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be noted: this is supposed to be a long double
, but I have absolutely no idea how to bind such a type... And the C spec is wonderful about it: https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
0c2939c
to
c76f177
Compare
238d71b
to
8e7db86
Compare
☔ The latest upstream changes (presumably #2556) made this pull request unmergeable. Please resolve the merge conflicts. |
5635d65
to
fba1905
Compare
I'm having trouble with errors like:
They are C enums but the comparison considers them as structs? Just in case, the C enums are defined here. |
fba1905
to
4d42380
Compare
☔ The latest upstream changes (presumably #2561) made this pull request unmergeable. Please resolve the merge conflicts. |
4d42380
to
03fb604
Compare
@JohnTitor Any idea about why I'm getting this error when using enums? |
97ac38e
to
f594d0a
Compare
Fixed the conflict. |
☔ The latest upstream changes (presumably #2574) made this pull request unmergeable. Please resolve the merge conflicts. |
b4a10f1
to
c4de1bc
Compare
Rebased. |
r? @Amanieu |
} else { | ||
pub type c_longdouble = [u8; 16]; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you checked that this actually works? I imagine that from a calling-convention point of view, a long double
is passed/returned differently from an array of u8
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know how to check it? I tried it on the C API and valgrind seemed fine with it but no clue if it isn't just plain luck at this point...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a few tests on godbolt:
- On x86 & x86_64, long doubles are passed in 80-bit x87 float registers. There is no way to represent this with normal Rust code.
- On aarch64, long doubles are passed in 128-bit SIMD registers. You can probably emulate this by using
uint64x2_t
from the (currently unstable) stdarch intrinsics.
In conclusion, I don't think it is practical to bind these API using Rust at the moment. I would recommend using a wrapper written in C to convert these values to a normal double
.
In the longer term, I plan on adding arch-specific types such as f80
, f128
, f16
, etc to stdarch, but this is unlikely to happen any time soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to make it private and remove the double functions using long double
and keeping it for the statinfo
struct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That might work, but you need to make sure that you have the correct size/alignment for c_longdouble
on all arches. My recommendation would be to search for LongDouble[Size|Align]
in clang/lib/Basic/Targets/
to get the correct values for all targets that FreeBSD supports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only test FreeBSD on one arch? :o
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only test it on x86_64. But we do test that it builds on x86_64, i686, aarch64 and powerpc64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you mean: are the types actually checked on the arch you mentioned or is it simply running a cargo build
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The types are only checked on x86_64 I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, that's pretty bad. :-/
c4de1bc
to
ad8e2c2
Compare
@Amanieu In the end, I simply commented everything related to |
I would prefer if the code was properly deleted, it's messy to leave commented code around. Also, the build.rs changes related to long double should also be removed. |
1f05b36
to
aa44de4
Compare
Ok, done as well. |
aa44de4
to
7a0d705
Compare
7a0d705
to
ac6e16b
Compare
@bors r+ |
📌 Commit ac6e16b has been approved by |
☀️ Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13 |
Hello! As you might know, We generally try to keep our dependencies up to date, and one of those is Adding new APIs is fine, of course, but would you mind pinging me next time you link to a new library so I can update the FreeBSD toolchain script? Even if we don't do this for RA, it still needed before upgrading EDIT: ideally we'd run FreeBSD on CI, but I'm not sure how to do it, and it's still not easy to keep our list of libraries in sync with what |
Gate PartialEq and Eq on freebsd objects behind extra_traits This fixes the failure in rust-lang/rust#93351 (comment). These derives were recently added in #2565. Other PartialEq/Eq derives in the project (and this file) are all behind the `extra_traits` gate.
No description provided.