Integration test for boot service function load_image

[phip1611]

A colleague of mine (ping @scholzp) was about to use the load_image function of UEFI boot services to load an image into memory. While working on a minimal example, he encountered an unintuitive bug. As a consequence, I thought it's useful to have a valid integration test for that function which others can use as template.

The test currently fails. What's wrong there with the chosen approach, @nicholasbishop ? UEFI fails with NOT_FOUND when load_image is executed.

Checklist

• Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
• Update the changelog (if necessary)

[medhefgo]

As to why strategy A fails: get_image_file_system() tries to exclusively open LoadedImage protocol on the handle, which you already have open in this test function.

Personally, I am not a fan of seeing this crate throwing exclusive opening of protocols down everyone's throat.

This is what the spec says about exclusive opening:

EXCLUSIVE Used by applications to gain exclusive access to a protocol interface. If any drivers have the protocol
interface opened with an attribute of BY_DRIVER, then an attempt will be made to remove them by calling the driver’s
Stop() function.

This does not sound like something you'd wanna be doing willy-nilly with any protocol you may wanna open. I can also see child EFI apps not being able to open their own LoadedImage protocol just because the parent didn't bother to put their use of it inside a scope to force dropping it before starting the child.

There is also the matter of firmware/drivers already having an exclusive handle to something (I cannot get a GOP handle exclusively on my ASUS firmware + nvidia combo for example). So nudging everyone to use exclusive mode is just gonna result in a lot of annoyance.

Yes, the spec is annoyingly vague about all these protocol opening things. But the fact is, everyone on the C-side uses the old HandleProtocol or OpenProtocol+GET_PROTOCOL and it seems to work in practice.

[phip1611]

Thanks very much @medhefgo for your help and advices! I've updated the PR.
Also what you've mentioned about open_protocol_exclusive is a very good point. Thanks for the input!

[nicholasbishop]

Personally, I am not a fan of seeing this crate throwing exclusive opening of protocols down everyone's throat.

Well, that's a bit extreme :) For cases where you don't want an exclusive protocol, open_protocol can be used. We don't force anyone to open in exclusive mode.

[nicholasbishop]

One note, there will be overlap between this test and https://github.com/rust-osdev/uefi-rs/pull/793/files for testing shell protocols. I'm not necessarily opposed to having a bit of duplication in the tests though, just pointing it out.

[medhefgo]

Well, that's a bit extreme :) For cases where you don't want an exclusive protocol, open_protocol can be used. We don't force anyone to open in exclusive mode.

Any rust programmer worth their salt will use the non-unsafe interface, that's as good as forcing them (especially when the unsafe version is also unergonomic wrt to parameters to pass). Whether that interface is better/does the right thing is the question.

[phip1611]

Any rust programmer worth their salt will use the non-unsafe interface, that's as good as forcing them

I agree, that's a valid point. Cognitive load is already relatively high in this crate when working with UEFI. So users will refrain from using more "unsafety" when there are "safe" interfaces

[phip1611]

Needs a rebase onto #849

[phip1611]

Are we good to go now? @nicholasbishop