Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 Minimal Std implementation for UEFI #105861
Add Minimal Std implementation for UEFI #105861
Changes from all commits
48c6ae0
8e56b33
032e376
5df24d1
7a95644
40c3dac
c7e5f3c
984ecef
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
As mentioned before, you stuff random pointers into argc/argv of
#[start]
. Instead, we could make the argument to#[start]
a struct (or union) that passes the platform arguments to#[start]
and avoid passing random data in argv.There is no way we can stabilize
#[start]
with this cross use. I am not convinced this is a good idea.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.
Could you clarify what the concern is here, exactly? Are we worrying about conflicting with someone else trying to use argc and argv, basically?
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 don't think there is an inherent conflict. But we would effectively make it impossible to use
#[start]
without platform knowledge. Because any crate that uses#[start]
must be adjusted toNOT
assumeargv
to be a c-string array for some platforms.Arguments passed to the individual startup routines differ strongly across platforms. Up until now
#[start]
simply got argc+argv in the unix-style iff the platform passed it, and "0/[0; 1]" (or "0/NULL", not sure) otherwise. Other arguments were just silently dropped, since the platform provides separate accessors (maybe I am wrong and there is precedence; but I didn't see any so far).There is some discussion in the tracking issue of
#[start]
(#29633), and I feel like there is consensus in using a custom enum to pass the data. But this is not like anyone is working on it, or any urgent need to implement it.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 believe complicating the use of an unstable feature which is, as you noted, fairly "stuck", is undesirable but not unexpected. I do not believe a slightly hacky implementation on this count is sufficient reason to bar this PR, although it ought to come with an appropriately huge
// FIXME
, unless you believe that this choice will somehow become impossible to overcome later.