@@ -56,13 +56,26 @@ impl<'boot> log::Log for Logger {
56
56
fn log ( & self , record : & log:: Record ) {
57
57
if let Some ( mut ptr) = self . writer {
58
58
let writer = unsafe { ptr. as_mut ( ) } ;
59
- // FIXME: Some UEFI firmware implementations e.g. VrtualBox's implementation
60
- // occasionally report a EFI_DEVICE_ERROR with some text dropped out within
61
- // SimpleTextOutput protocol, which is a firmware bug. In that case, we will
62
- // get a `fmt::Error` here. Since the `log` crate gives no other option to
63
- // deal with output errors, we ignore the `Result` here to prevent potential
64
- // panics from happening.
65
- DecoratedLog :: write ( writer, record. level ( ) , record. args ( ) ) . unwrap_or_default ( ) ;
59
+ let result = DecoratedLog :: write ( writer, record. level ( ) , record. args ( ) ) ;
60
+
61
+ // Some UEFI implementations, such as the one used by VirtualBox,
62
+ // may intermittently drop out some text from SimpleTextOutput and
63
+ // report an EFI_DEVICE_ERROR. This will be reported here as an
64
+ // `fmt::Error`, and given how the `log` crate is designed, our main
65
+ // choices when that happens are to ignore the error or panic.
66
+ //
67
+ // Ignoring errors is bad, especially when they represent loss of
68
+ // precious early-boot system diagnosis data, so we panic by
69
+ // default. But if you experience this problem and want your UEFI
70
+ // application to keep running when it happens, you can enable the
71
+ // `ignore-logger-error` cargo feature. If you do so, logging errors
72
+ // will be ignored by `uefi-rs` instead.
73
+ //
74
+ if cfg ! ( feature = "ignore-logger-errors" ) {
75
+ core:: mem:: drop ( result)
76
+ } else {
77
+ result. unwrap ( )
78
+ }
66
79
}
67
80
}
68
81
0 commit comments