-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Add libstd support for Trusty targets #136842
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
Changes from all commits
87ca2db
7f6ee12
d633d8e
22fea97
5b94113
0b1a7ab
f5dd3d1
2b3b0bd
d3c55cd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -169,6 +169,8 @@ pub mod rtems; | |
pub mod solaris; | ||
#[cfg(target_os = "solid_asp3")] | ||
pub mod solid; | ||
#[cfg(target_os = "trusty")] | ||
pub mod trusty; | ||
#[cfg(target_os = "uefi")] | ||
pub mod uefi; | ||
#[cfg(target_os = "vita")] | ||
|
@@ -178,7 +180,7 @@ pub mod vxworks; | |
#[cfg(target_os = "xous")] | ||
pub mod xous; | ||
|
||
#[cfg(any(unix, target_os = "hermit", target_os = "wasi", doc))] | ||
#[cfg(any(unix, target_os = "hermit", target_os = "trusty", target_os = "wasi", doc))] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This whole module is about providing safe abstractions for file descriptors that maintain IO safety. But if I understand the documentation correctly, there is no way to open or close file descriptors on Trusty, meaning the whole concept of IO safety is unnecessary. Thus I don't think that this module should exist on Trusty. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We do make heavy use of |
||
pub mod fd; | ||
|
||
#[cfg(any(target_os = "linux", target_os = "android", doc))] | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
#![stable(feature = "os_fd", since = "1.66.0")] | ||
|
||
#[stable(feature = "os_fd", since = "1.66.0")] | ||
pub use crate::os::fd::*; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
#![stable(feature = "rust1", since = "1.0.0")] | ||
|
||
pub mod io; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
//! System bindings for the Trusty OS. | ||
|
||
#[path = "../unsupported/args.rs"] | ||
pub mod args; | ||
#[path = "../unsupported/common.rs"] | ||
#[deny(unsafe_op_in_unsafe_fn)] | ||
mod common; | ||
#[path = "../unsupported/env.rs"] | ||
pub mod env; | ||
#[path = "../unsupported/os.rs"] | ||
pub mod os; | ||
#[path = "../unsupported/pipe.rs"] | ||
pub mod pipe; | ||
#[path = "../unsupported/process.rs"] | ||
pub mod process; | ||
#[path = "../unsupported/thread.rs"] | ||
pub mod thread; | ||
#[path = "../unsupported/time.rs"] | ||
pub mod time; | ||
|
||
pub use common::*; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
extern "C" { | ||
fn trusty_rng_secure_rand(randomBuffer: *mut core::ffi::c_void, randomBufferLen: libc::size_t); | ||
} | ||
|
||
pub fn fill_bytes(bytes: &mut [u8]) { | ||
unsafe { trusty_rng_secure_rand(bytes.as_mut_ptr().cast(), bytes.len()) } | ||
} |
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.
Adding a bunch of
cfg
seems like a tacit admission that this implementation is not very useful, and depends on certain implementations never being even referenced.In general, we have avoided adding
cfg
to the implementations of std. I do not think we should get in the habit here.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.
Is there a better approach to follow for disabling unsupported parts of std? Would it be better to instead stub out platform APIs with
unimplemented!
? That would involve fewercfg
s, though I'm not sure how to handle tests with that approach.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.
There is really no satisfactory answer, to be clear, which is why we have shifted towards being increasingly reluctant to allow targets to add only partial support for std.