Add documentation about logging/allocating after exiting boot services

[nicholasbishop]

The logger and allocator provided by the uefi crate can't be used after
calling exit_boot_services. Add a paragraph to exit_boot_services to
document that. Add a similar paragraph to the uefi-services crate
documentation.

[GabrielMajeri]

The doc changes look good, but I was wondering if we can't come up with an even better/automatic solution for the safe disabling of the logger. UEFI defines a SIGNAL_EXIT_BOOT_SERVICES event which we could hook into at logger creation, and use it to automatically disable the logger instance. Would this solution help prevent undefined behavior after boot services are exited?

[nicholasbishop]

If logging was initialized with uefi_services::init then it already uses SIGNAL_EXIT_BOOT_SERVICES to disable the logger: https://github.com/rust-osdev/uefi-rs/blob/master/uefi-services/src/lib.rs#L80. So there's only undefined behavior with logging after exit_boot_services if someone writes their own logging initialization code and doesn't hook into the signal in the same way.

Maybe it would be possible to set up some static bool in the uefi crate that indicates whether boot services have been exited, and internally disable the logger if so. (I think some extra static would be needed because the static LOGGER is in uefi_services, not uefi.) Is that the kind of thing you were thinking of here?

I guess it also depends a bit on what the intended separation between the uefi and uefi_services crates is, like is it desired that the uefi crate can do stuff "behind the scenes" by registering event callbacks, as opposed to only doing UEFI operations explicitly requested by the user of the crate?

[GabrielMajeri]

If logging was initialized with uefi_services::init then it already uses SIGNAL_EXIT_BOOT_SERVICES to disable the logger

Ah, I must've forgotten we already have support for this.

I was thinking of moving the callback event into uefi, but your comment does make me realize this would go against the philosophy of the core uefi crate / the separation of concerns we currently have (uefi is "dumb" and doesn't do anything automatically, uefi-services provides all the conveniences).