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

Stdio support for UEFI #116207

Merged
merged 2 commits into from
Oct 2, 2023
Merged

Stdio support for UEFI #116207

merged 2 commits into from
Oct 2, 2023

Conversation

Ayush1325
Copy link
Contributor

@Ayush1325 Ayush1325 commented Sep 27, 2023

  • Uses Simple Text Output Protocol and Simple Text Input Protocol
  • Reading is done one character at a time
  • Writing is done with max 4096 characters

Quirks

Output Newline

  • UEFI uses CRLF for newline. So when running the application in UEFI shell (qemu VGA), the output of println looks weird.
  • However, since the UEFI shell supports piping output, I am unsure if doing any output post-processing is a good idea. UEFI shell cat command seems to work fine with just LF.

Input Newline

  • Stdin.read_line() method is broken in UEFI shell. Pressing enter seems to be read as CR, which means LF is never encountered.
  • Works fine with input redirection from file.

CC @dvdhrm

@rustbot
Copy link
Collaborator

rustbot commented Sep 27, 2023

r? @Mark-Simulacrum

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 27, 2023
@Mark-Simulacrum
Copy link
Member

cc @nicholasbishop as well as the other target maintainer

- Mention stdio support
- Update the example

Signed-off-by: Ayush Singh <[email protected]>
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters

Signed-off-by: Ayush Singh <[email protected]>
@Mark-Simulacrum
Copy link
Member

Code looks reasonable to me, though I haven't checked the UEFI ~FFI calls. I'll go ahead and approve as well.

@bors r+

@bors
Copy link
Contributor

bors commented Oct 1, 2023

📌 Commit 3f4a289 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2023
@bors
Copy link
Contributor

bors commented Oct 2, 2023

⌛ Testing commit 3f4a289 with merge 79bfd93...

@bors
Copy link
Contributor

bors commented Oct 2, 2023

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 79bfd93 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 2, 2023
@bors bors merged commit 79bfd93 into rust-lang:master Oct 2, 2023
11 checks passed
@rustbot rustbot added this to the 1.75.0 milestone Oct 2, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (79bfd93): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.0% [1.1%, 2.5%] 16
Regressions ❌
(secondary)
3.3% [3.3%, 3.3%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.0% [1.1%, 2.5%] 16

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 629.592s -> 626.835s (-0.44%)
Artifact size: 273.34 MiB -> 273.31 MiB (-0.01%)

@Ayush1325 Ayush1325 deleted the uefi_stdio branch October 2, 2023 06:20
bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request Oct 5, 2023
23: Fix divergence from upstream `master` r=tshepang a=pvdrz

* rust-lang/rust#116381
* rust-lang/rust#116360
* rust-lang/rust#116353
* rust-lang/rust#116406
* rust-lang/rust#116408
  * rust-lang/rust#116395
  * rust-lang/rust#116393
  * rust-lang/rust#116388
  * rust-lang/rust#116365
  * rust-lang/rust#116363
  * rust-lang/rust#116146
  * rust-lang/rust#115961
* rust-lang/rust#116386
* rust-lang/rust#116367
* rust-lang/rust#105394
* rust-lang/rust#115301
* rust-lang/rust#116384
  * rust-lang/rust#116379
  * rust-lang/rust#116328
  * rust-lang/rust#116282
  * rust-lang/rust#116261
  * rust-lang/rust#114654
* rust-lang/rust#116376
  * rust-lang/rust#116374
  * rust-lang/rust#116371
  * rust-lang/rust#116358
  * rust-lang/rust#116210
  * rust-lang/rust#115863
* rust-lang/rust#115025
* rust-lang/rust#116372
  * rust-lang/rust#116361
  * rust-lang/rust#116355
  * rust-lang/rust#116351
  * rust-lang/rust#116158
  * rust-lang/rust#115726
  * rust-lang/rust#113053
* rust-lang/rust#116083
* rust-lang/rust#102099
* rust-lang/rust#116356
  * rust-lang/rust#116350
  * rust-lang/rust#116349
  * rust-lang/rust#116289
  * rust-lang/rust#114454
  * rust-lang/rust#114453
* rust-lang/rust#116331
* rust-lang/rust#116346
  * rust-lang/rust#116340
  * rust-lang/rust#116326
  * rust-lang/rust#116313
* rust-lang/rust#116276
* rust-lang/rust#115898
* rust-lang/rust#116325
* rust-lang/rust#116317
* rust-lang/rust#116207
* rust-lang/rust#116281
* rust-lang/rust#116304
* rust-lang/rust#116259
* rust-lang/rust#116228
* rust-lang/rust#116224
* rust-lang/rust#115554
* rust-lang/rust#116311
  * rust-lang/rust#116299
  * rust-lang/rust#116295
  * rust-lang/rust#116292
* rust-lang/rust#116307
* rust-lang/rust#115670
* rust-lang/rust#116225
* rust-lang/rust#116302
* rust-lang/rust#116108
* rust-lang/rust#116160
* rust-lang/rust#116157
* rust-lang/rust#116127
* rust-lang/rust#116286
* rust-lang/rust#116254
* rust-lang/rust#116195
* rust-lang/rust#116280
* rust-lang/rust#115933
* rust-lang/rust#115546
* rust-lang/rust#115368
* rust-lang/rust#116275
  * rust-lang/rust#116263
  * rust-lang/rust#116241
  * rust-lang/rust#116216
  * rust-lang/rust#116030
  * rust-lang/rust#116024
  * rust-lang/rust#112123
* rust-lang/rust#113301
* rust-lang/rust#113797
* rust-lang/rust#115759
* rust-lang/rust#116260
  * rust-lang/rust#116253
  * rust-lang/rust#116245
  * rust-lang/rust#116239
  * rust-lang/rust#116234
  * rust-lang/rust#116231
  * rust-lang/rust#116201
  * rust-lang/rust#116133
* rust-lang/rust#116176
* rust-lang/rust#116089
* rust-lang/rust#115986



Co-authored-by: ouz-a <[email protected]>
Co-authored-by: Jakub Beránek <[email protected]>
Co-authored-by: Federico Stra <[email protected]>
Co-authored-by: bohan <[email protected]>
Co-authored-by: Jason Newcomb <[email protected]>
Co-authored-by: Ralf Jung <[email protected]>
Co-authored-by: bors <[email protected]>
Co-authored-by: Oli Scherer <[email protected]>
use crate::os::uefi;
use crate::ptr::NonNull;

const MAX_BUFFER_SIZE: usize = 8192;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this sized based on 2 pages, rather than the more common single page size?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, that size was picked up from Windows implementation. I am open to a more appropriate size.

Copy link
Contributor

Choose a reason for hiding this comment

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

The windows backend picked 8k due to behavior of the windows system libraries (also see f411852). I don't think any of this reasoning applies to UEFI.

}

pub fn panic_output() -> Option<impl io::Write> {
uefi::env::try_system_table().map(|_| Stderr::new())
Copy link
Contributor

Choose a reason for hiding this comment

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

Why checking for the system-table here? It can be invalidated in a parallel call.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am not sure what you mean. My intention was to check if the code panics before the system table is initialized in Rust (which can happen) or after it. It is not really meant to check if system table is valid for complete UEFI.

Copy link
Contributor

Choose a reason for hiding this comment

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

But why do you check for it? What is the rationale?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To avoid panic inside panic.

pub const STDIN_BUF_SIZE: usize = 3;

pub fn is_ebadf(_err: &io::Error) -> bool {
true
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the reasoning here? You effectively fold every error to the default error by treating everything as EBADF, or what am I missing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's just the default unsupported implementation. I am not sure what EBADF corresponds to in UEFI. Feel free to comment about it.

Copy link
Contributor

Choose a reason for hiding this comment

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

is_ebadf() is used to suppress EBADF errors, and avoid panicking on println!() if the output-stream does not exist. Your current implementation for UEFI causes ALL errors for output-streams to be suppressed, because you unconditionally return true.

There is no equivalent to EBADF on UEFI, since you operate on devices directly, rather than on virtualized FDs. However, you likely want to suppress EFI_UNSUPPORTED, since this is triggered when text-mode is currently disabled. But is_ebadf() seems like the wrong place to do this.

protocol: *mut r_efi::protocols::simple_text_output::Protocol,
buf: &[u8],
) -> io::Result<usize> {
let mut utf16 = [0; MAX_BUFFER_SIZE / 2];
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe use an explicit type-annotation here? You rely on the size of the type by hard-coding 2, yet no explicit type is used.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I guess it can be changed to size_of::<u16>(). I started with the windows implementation so it is from that.

Copy link
Contributor

Choose a reason for hiding this comment

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

I am not talking about the sizeof_of, I am talking about the type-annotation of utf16 (let mut utf16: u16 = ...).

Err(e) => unsafe { crate::str::from_utf8_unchecked(&buf[..e.valid_up_to()]) },
};
// Clip UTF-8 buffer to max UTF-16 buffer we support
let utf8 = &utf8[..utf8.floor_char_boundary(utf16.len() - 1)];
Copy link
Contributor

Choose a reason for hiding this comment

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

The - 1 should be dropped. floor_char_boundary() will correctly use the entire string if the index is beyond the last character.

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 the -1 is so that the string is NULL terminated.

Copy link
Contributor

Choose a reason for hiding this comment

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

Fair enough. Though, I think this is really not obvious from this code. And simple_text_output() takes a slice but silently expects it to be NULL-terminated. I think this is very likely to lead to problems. I would prefer at least an assertion in simple_text_output() to catch such errors in the future.


impl io::Write for Stderr {
fn write(&mut self, buf: &[u8]) -> io::Result<usize> {
let st: NonNull<r_efi::efi::SystemTable> = uefi::env::system_table().cast();
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not error out if the system-table is not available?

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 the current implementation has a default behaviour to panic if system table (and brothers) is not available. The exceptions are when the function might be called before sys::init.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I know. I want to understand what you want the behavior to be when it is called before sys::init? You check for validity in the panic-path, but not here, which seems inconsistent. I am simply trying to understand what you want it to behave like?

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 the basic assumptions is that SystemTable and ImageHandle are always valid except in panic-path. Thus, anything that uses Stderr outside of panic-path should panic if it is unavailable.

// Check if the key is printiable character
if inp.scan_code != 0x00 {
return Err(io::const_io_error!(io::ErrorKind::Interrupted, "Special Key Press"));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you explain why you strip zeros?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not stripping zeros, scan_code not 0 indicates a non-printable character. See Section 12.3.3 in UEFI Spec

Copy link
Contributor

Choose a reason for hiding this comment

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

unicode_char == 0x00 represents control characters. The scan-code is always set, yet you check the scan-code rather than unicode_char.

If I am not mistaken, your current code suppresses all input.

The ReadKeyStroke() function reads the next keystroke from the input device. If there is no pending keystroke the
function returns EFI_NOT_READY. If there is a pending keystroke, then ScanCode is the EFI scan code defined in
EFI Scan Codes for EFI_SIMPLE_TEXT_INPUT_PROTOCOL . The UnicodeChar is the actual printable character or
is zero if the key does not represent a printable character (control key, function key, etc.)

}

// SAFETY: Iterator will have only 1 character since we are reading only 1 Key
// SAFETY: This character will always be UCS-2 and thus no surrogates.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it is overly optimistic to rely on firmware never returning invalid data. I would prefer to forward errors, but I will not insist.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since we are reading a printable key press (due to the above check), I would hope it would be valid. But since it is possible to do file piping for input, I guess it might be good to return an error.

// SAFETY: This character will always be UCS-2 and thus no surrogates.
let ch: char = char::decode_utf16([inp.unicode_char]).next().unwrap().unwrap();
if ch.len_utf8() > buf.len() {
return Ok(0);
Copy link
Contributor

Choose a reason for hiding this comment

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

You drop data if the buffer is short. This is really unfortunate. I think the better alternative would be to have an internal buffer in struct Stdin where you keep the last char and keep trying to return it to the caller until they provide a suitable buffer. This does busy-loop if the caller never provides a suitable buffer, but at least you do not drop data silently.

Alternatively, return exactly the requested amount of bytes, and return the remaining ones in following calls. There is no reason why the caller would expect every read-call to split exactly at UTF8-boundaries, or is there?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it seems like a reasonable strategy. I think an internal buffer of a single character (u16) should be enough.

Err(e) if e == r_efi::efi::Status::NOT_READY => {
// Wait for keypress for new data
wait_stdin(stdin)?;
read_key_stroke(stdin).map_err(|x| io::Error::from_raw_os_error(x.as_usize()))?
Copy link
Contributor

Choose a reason for hiding this comment

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

Any particular reason you do not loop on NOT_READY? Can we rely on wait_stdin to never report spurious wakeups?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, I am not sure busy waiting would be the best idea. In all the examples of reading I have seen online, everyone seems to rely on the con_in->wait_for_key event.
The spec also states the following: "Event to use with EFI_BOOT_SERVICES.WaitForEvent() to wait for a key to be available." So it should be the best solution.

Copy link
Contributor

Choose a reason for hiding this comment

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

I am not suggesting busy-waiting. I am saying to loop on NOT_READY. So after wait_stdin(), you still check for NOT_READY and wait again if it keeps getting reported.

bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request Oct 6, 2023
23: Fix divergence from upstream `master` r=tshepang a=pvdrz

* rust-lang/rust#116483
  * rust-lang/rust#116475
  * rust-lang/rust#116329
  * rust-lang/rust#116198
  * rust-lang/rust#115588
  * rust-lang/rust#115522
  * rust-lang/rust#115454
* rust-lang/rust#111595
* rust-lang/rust#116018
* rust-lang/rust#116472
  * rust-lang/rust#116469
  * rust-lang/rust#116421
* rust-lang/rust#116463
* rust-lang/rust#101150
* rust-lang/rust#116269
* rust-lang/rust#116417
* rust-lang/rust#116455
  * rust-lang/rust#116452
  * rust-lang/rust#116428
  * rust-lang/rust#116415
  * rust-lang/rust#116288
  * rust-lang/rust#116220
* rust-lang/rust#103046
* rust-lang/rust#114042
* rust-lang/rust#104153
* rust-lang/rust#116427
* rust-lang/rust#116443
  * rust-lang/rust#116432
  * rust-lang/rust#116431
  * rust-lang/rust#116429
  * rust-lang/rust#116296
  * rust-lang/rust#116223
* rust-lang/rust#116273
* rust-lang/rust#116184
* rust-lang/rust#116370
* rust-lang/rust#114417
* rust-lang/rust#115200
* rust-lang/rust#116413
* rust-lang/rust#116381
* rust-lang/rust#116360
* rust-lang/rust#116353
* rust-lang/rust#116406
* rust-lang/rust#116408
  * rust-lang/rust#116395
  * rust-lang/rust#116393
  * rust-lang/rust#116388
  * rust-lang/rust#116365
  * rust-lang/rust#116363
  * rust-lang/rust#116146
  * rust-lang/rust#115961
* rust-lang/rust#116386
* rust-lang/rust#116367
* rust-lang/rust#105394
* rust-lang/rust#115301
* rust-lang/rust#116384
  * rust-lang/rust#116379
  * rust-lang/rust#116328
  * rust-lang/rust#116282
  * rust-lang/rust#116261
  * rust-lang/rust#114654
* rust-lang/rust#116376
  * rust-lang/rust#116374
  * rust-lang/rust#116371
  * rust-lang/rust#116358
  * rust-lang/rust#116210
  * rust-lang/rust#115863
* rust-lang/rust#115025
* rust-lang/rust#116372
  * rust-lang/rust#116361
  * rust-lang/rust#116355
  * rust-lang/rust#116351
  * rust-lang/rust#116158
  * rust-lang/rust#115726
  * rust-lang/rust#113053
* rust-lang/rust#116083
* rust-lang/rust#102099
* rust-lang/rust#116356
  * rust-lang/rust#116350
  * rust-lang/rust#116349
  * rust-lang/rust#116289
  * rust-lang/rust#114454
  * rust-lang/rust#114453
* rust-lang/rust#116331
* rust-lang/rust#116346
  * rust-lang/rust#116340
  * rust-lang/rust#116326
  * rust-lang/rust#116313
* rust-lang/rust#116276
* rust-lang/rust#115898
* rust-lang/rust#116325
* rust-lang/rust#116317
* rust-lang/rust#116207
* rust-lang/rust#116281
* rust-lang/rust#116304
* rust-lang/rust#116259
* rust-lang/rust#116228
* rust-lang/rust#116224
* rust-lang/rust#115554
* rust-lang/rust#116311
  * rust-lang/rust#116299
  * rust-lang/rust#116295
  * rust-lang/rust#116292
* rust-lang/rust#116307
* rust-lang/rust#115670
* rust-lang/rust#116225
* rust-lang/rust#116302
* rust-lang/rust#116108
* rust-lang/rust#116160
* rust-lang/rust#116157
* rust-lang/rust#116127
* rust-lang/rust#116286
* rust-lang/rust#116254
* rust-lang/rust#116195
* rust-lang/rust#116280
* rust-lang/rust#115933
* rust-lang/rust#115546
* rust-lang/rust#115368
* rust-lang/rust#116275
  * rust-lang/rust#116263
  * rust-lang/rust#116241
  * rust-lang/rust#116216
  * rust-lang/rust#116030
  * rust-lang/rust#116024
  * rust-lang/rust#112123
* rust-lang/rust#113301
* rust-lang/rust#113797
* rust-lang/rust#115759
* rust-lang/rust#116260
  * rust-lang/rust#116253
  * rust-lang/rust#116245
  * rust-lang/rust#116239
  * rust-lang/rust#116234
  * rust-lang/rust#116231
  * rust-lang/rust#116201
  * rust-lang/rust#116133
* rust-lang/rust#116176
* rust-lang/rust#116089
* rust-lang/rust#115986

Co-authored-by: ouz-a <[email protected]>
Co-authored-by: bors <[email protected]>
Co-authored-by: Samuel Thibault <[email protected]>
Co-authored-by: linkmauve <[email protected]>
Co-authored-by: onur-ozkan <[email protected]>
Co-authored-by: asquared31415 <[email protected]>
Co-authored-by: Emmanuel Ferdman <[email protected]>
Co-authored-by: Ralf Jung <[email protected]>
Co-authored-by: Nadrieril <[email protected]>
Co-authored-by: Raekye <[email protected]>
Co-authored-by: Mark Rousskov <[email protected]>
Co-authored-by: Zalathar <[email protected]>
bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request Oct 9, 2023
23: Fix divergence from upstream `master` r=pietroalbini a=pvdrz

* rust-lang/rust#116483
  * rust-lang/rust#116475
  * rust-lang/rust#116329
  * rust-lang/rust#116198
  * rust-lang/rust#115588
  * rust-lang/rust#115522
  * rust-lang/rust#115454
* rust-lang/rust#111595
* rust-lang/rust#116018
* rust-lang/rust#116472
  * rust-lang/rust#116469
  * rust-lang/rust#116421
* rust-lang/rust#116463
* rust-lang/rust#101150
* rust-lang/rust#116269
* rust-lang/rust#116417
* rust-lang/rust#116455
  * rust-lang/rust#116452
  * rust-lang/rust#116428
  * rust-lang/rust#116415
  * rust-lang/rust#116288
  * rust-lang/rust#116220
* rust-lang/rust#103046
* rust-lang/rust#114042
* rust-lang/rust#104153
* rust-lang/rust#116427
* rust-lang/rust#116443
  * rust-lang/rust#116432
  * rust-lang/rust#116431
  * rust-lang/rust#116429
  * rust-lang/rust#116296
  * rust-lang/rust#116223
* rust-lang/rust#116273
* rust-lang/rust#116184
* rust-lang/rust#116370
* rust-lang/rust#114417
* rust-lang/rust#115200
* rust-lang/rust#116413
* rust-lang/rust#116381
* rust-lang/rust#116360
* rust-lang/rust#116353
* rust-lang/rust#116406
* rust-lang/rust#116408
  * rust-lang/rust#116395
  * rust-lang/rust#116393
  * rust-lang/rust#116388
  * rust-lang/rust#116365
  * rust-lang/rust#116363
  * rust-lang/rust#116146
  * rust-lang/rust#115961
* rust-lang/rust#116386
* rust-lang/rust#116367
* rust-lang/rust#105394
* rust-lang/rust#115301
* rust-lang/rust#116384
  * rust-lang/rust#116379
  * rust-lang/rust#116328
  * rust-lang/rust#116282
  * rust-lang/rust#116261
  * rust-lang/rust#114654
* rust-lang/rust#116376
  * rust-lang/rust#116374
  * rust-lang/rust#116371
  * rust-lang/rust#116358
  * rust-lang/rust#116210
  * rust-lang/rust#115863
* rust-lang/rust#115025
* rust-lang/rust#116372
  * rust-lang/rust#116361
  * rust-lang/rust#116355
  * rust-lang/rust#116351
  * rust-lang/rust#116158
  * rust-lang/rust#115726
  * rust-lang/rust#113053
* rust-lang/rust#116083
* rust-lang/rust#102099
* rust-lang/rust#116356
  * rust-lang/rust#116350
  * rust-lang/rust#116349
  * rust-lang/rust#116289
  * rust-lang/rust#114454
  * rust-lang/rust#114453
* rust-lang/rust#116331
* rust-lang/rust#116346
  * rust-lang/rust#116340
  * rust-lang/rust#116326
  * rust-lang/rust#116313
* rust-lang/rust#116276
* rust-lang/rust#115898
* rust-lang/rust#116325
* rust-lang/rust#116317
* rust-lang/rust#116207
* rust-lang/rust#116281
* rust-lang/rust#116304
* rust-lang/rust#116259
* rust-lang/rust#116228
* rust-lang/rust#116224
* rust-lang/rust#115554
* rust-lang/rust#116311
  * rust-lang/rust#116299
  * rust-lang/rust#116295
  * rust-lang/rust#116292
* rust-lang/rust#116307
* rust-lang/rust#115670
* rust-lang/rust#116225
* rust-lang/rust#116302
* rust-lang/rust#116108
* rust-lang/rust#116160
* rust-lang/rust#116157
* rust-lang/rust#116127
* rust-lang/rust#116286
* rust-lang/rust#116254
* rust-lang/rust#116195
* rust-lang/rust#116280
* rust-lang/rust#115933
* rust-lang/rust#115546
* rust-lang/rust#115368
* rust-lang/rust#116275
  * rust-lang/rust#116263
  * rust-lang/rust#116241
  * rust-lang/rust#116216
  * rust-lang/rust#116030
  * rust-lang/rust#116024
  * rust-lang/rust#112123
* rust-lang/rust#113301
* rust-lang/rust#113797
* rust-lang/rust#115759
* rust-lang/rust#116260
  * rust-lang/rust#116253
  * rust-lang/rust#116245
  * rust-lang/rust#116239
  * rust-lang/rust#116234
  * rust-lang/rust#116231
  * rust-lang/rust#116201
  * rust-lang/rust#116133
* rust-lang/rust#116176
* rust-lang/rust#116089
* rust-lang/rust#115986

Co-authored-by: bors <[email protected]>
Co-authored-by: ouz-a <[email protected]>
Co-authored-by: Samuel Thibault <[email protected]>
Co-authored-by: linkmauve <[email protected]>
Co-authored-by: onur-ozkan <[email protected]>
Co-authored-by: asquared31415 <[email protected]>
Co-authored-by: Emmanuel Ferdman <[email protected]>
Co-authored-by: Ralf Jung <[email protected]>
Co-authored-by: Nadrieril <[email protected]>
Co-authored-by: Raekye <[email protected]>
Co-authored-by: Mark Rousskov <[email protected]>
Co-authored-by: Zalathar <[email protected]>
bors-ferrocene bot added a commit to ferrocene/ferrocene that referenced this pull request Oct 9, 2023
23: Fix divergence from upstream `master` r=Dajamante a=pvdrz

* rust-lang/rust#116483
  * rust-lang/rust#116475
  * rust-lang/rust#116329
  * rust-lang/rust#116198
  * rust-lang/rust#115588
  * rust-lang/rust#115522
  * rust-lang/rust#115454
* rust-lang/rust#111595
* rust-lang/rust#116018
* rust-lang/rust#116472
  * rust-lang/rust#116469
  * rust-lang/rust#116421
* rust-lang/rust#116463
* rust-lang/rust#101150
* rust-lang/rust#116269
* rust-lang/rust#116417
* rust-lang/rust#116455
  * rust-lang/rust#116452
  * rust-lang/rust#116428
  * rust-lang/rust#116415
  * rust-lang/rust#116288
  * rust-lang/rust#116220
* rust-lang/rust#103046
* rust-lang/rust#114042
* rust-lang/rust#104153
* rust-lang/rust#116427
* rust-lang/rust#116443
  * rust-lang/rust#116432
  * rust-lang/rust#116431
  * rust-lang/rust#116429
  * rust-lang/rust#116296
  * rust-lang/rust#116223
* rust-lang/rust#116273
* rust-lang/rust#116184
* rust-lang/rust#116370
* rust-lang/rust#114417
* rust-lang/rust#115200
* rust-lang/rust#116413
* rust-lang/rust#116381
* rust-lang/rust#116360
* rust-lang/rust#116353
* rust-lang/rust#116406
* rust-lang/rust#116408
  * rust-lang/rust#116395
  * rust-lang/rust#116393
  * rust-lang/rust#116388
  * rust-lang/rust#116365
  * rust-lang/rust#116363
  * rust-lang/rust#116146
  * rust-lang/rust#115961
* rust-lang/rust#116386
* rust-lang/rust#116367
* rust-lang/rust#105394
* rust-lang/rust#115301
* rust-lang/rust#116384
  * rust-lang/rust#116379
  * rust-lang/rust#116328
  * rust-lang/rust#116282
  * rust-lang/rust#116261
  * rust-lang/rust#114654
* rust-lang/rust#116376
  * rust-lang/rust#116374
  * rust-lang/rust#116371
  * rust-lang/rust#116358
  * rust-lang/rust#116210
  * rust-lang/rust#115863
* rust-lang/rust#115025
* rust-lang/rust#116372
  * rust-lang/rust#116361
  * rust-lang/rust#116355
  * rust-lang/rust#116351
  * rust-lang/rust#116158
  * rust-lang/rust#115726
  * rust-lang/rust#113053
* rust-lang/rust#116083
* rust-lang/rust#102099
* rust-lang/rust#116356
  * rust-lang/rust#116350
  * rust-lang/rust#116349
  * rust-lang/rust#116289
  * rust-lang/rust#114454
  * rust-lang/rust#114453
* rust-lang/rust#116331
* rust-lang/rust#116346
  * rust-lang/rust#116340
  * rust-lang/rust#116326
  * rust-lang/rust#116313
* rust-lang/rust#116276
* rust-lang/rust#115898
* rust-lang/rust#116325
* rust-lang/rust#116317
* rust-lang/rust#116207
* rust-lang/rust#116281
* rust-lang/rust#116304
* rust-lang/rust#116259
* rust-lang/rust#116228
* rust-lang/rust#116224
* rust-lang/rust#115554
* rust-lang/rust#116311
  * rust-lang/rust#116299
  * rust-lang/rust#116295
  * rust-lang/rust#116292
* rust-lang/rust#116307
* rust-lang/rust#115670
* rust-lang/rust#116225
* rust-lang/rust#116302
* rust-lang/rust#116108
* rust-lang/rust#116160
* rust-lang/rust#116157
* rust-lang/rust#116127
* rust-lang/rust#116286
* rust-lang/rust#116254
* rust-lang/rust#116195
* rust-lang/rust#116280
* rust-lang/rust#115933
* rust-lang/rust#115546
* rust-lang/rust#115368
* rust-lang/rust#116275
  * rust-lang/rust#116263
  * rust-lang/rust#116241
  * rust-lang/rust#116216
  * rust-lang/rust#116030
  * rust-lang/rust#116024
  * rust-lang/rust#112123
* rust-lang/rust#113301
* rust-lang/rust#113797
* rust-lang/rust#115759
* rust-lang/rust#116260
  * rust-lang/rust#116253
  * rust-lang/rust#116245
  * rust-lang/rust#116239
  * rust-lang/rust#116234
  * rust-lang/rust#116231
  * rust-lang/rust#116201
  * rust-lang/rust#116133
* rust-lang/rust#116176
* rust-lang/rust#116089
* rust-lang/rust#115986

35: Automated pull from `rust-lang/libc` r=pietroalbini a=github-actions[bot]

This PR pulls the following changes from the [`rust-lang/libc`](https://github.com/rust-lang/libc) repository:

* rust-lang/libc#3335
* rust-lang/libc#3373
* rust-lang/libc#3360
* rust-lang/libc#3374
* rust-lang/libc#3375
* rust-lang/libc#3376
* rust-lang/libc#3377


Co-authored-by: ouz-a <[email protected]>
Co-authored-by: Samuel Thibault <[email protected]>
Co-authored-by: bors <[email protected]>
Co-authored-by: linkmauve <[email protected]>
Co-authored-by: onur-ozkan <[email protected]>
Co-authored-by: asquared31415 <[email protected]>
Co-authored-by: Emmanuel Ferdman <[email protected]>
Co-authored-by: Ralf Jung <[email protected]>
Co-authored-by: Nadrieril <[email protected]>
Co-authored-by: Raekye <[email protected]>
Co-authored-by: Mark Rousskov <[email protected]>
Co-authored-by: Zalathar <[email protected]>
Co-authored-by: Nikolay Arhipov <[email protected]>
Co-authored-by: Brian Cain <[email protected]>
Co-authored-by: Steve Lau <[email protected]>
Co-authored-by: David CARLIER <[email protected]>
Co-authored-by: Louis Dupré Bertoni <[email protected]>
Co-authored-by: Taiki Endo <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@Ayush1325 Ayush1325 mentioned this pull request Oct 25, 2023
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 22, 2024
…ingjubilee

Improve UEFI stdio

Fixed some things suggested in last PR: rust-lang#116207

cc `@dvdhrm`
cc `@nicholasbishop`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants