Proper usage of Bridge/Attachment outside of EntryPoint?

[schockjd]

I'm exploring how I might use this crate to provide allocation in a scenario where I have a UEFI driver publishing a protocol and where the protocol routines are invoked by other drivers/core independent of the entry point. In the examples here, the global allocator bridge is set up by being attached in the entry point, but then, when the entry point returns, the attachment will go out of scope and get dropped. This means that the global allocator bridge wouldn't be valid for the calls into the protocol routines.

It seems like there might be two ways about it (and maybe the correct way is one I haven't thought of):

1. Stash the system table pointer in a global static and use it to re-attach the bridge in every call that comes from the core outside the entry point. In the general case it could be that some of the protocol routines could be called async (e.g. from timer or event callback) leading to an attempt at a "double attach" - which I think could be a challenge if the first attach is somehow dropped while the second exists. I can't think of a way that this ordering issue could occur, but it seems risky.
2. Attach the bridge in the entry point and somehow move the resulting attach into a static so out it outlives the entry point and remains valid for calls into the published protocol instance. I haven't quite convinced the borrow checker that this is a good idea yet though.

In any case, some guidance about expected usage in this scenario would be greatly appreciated.

[dvdhrm]

I think the easiest solution would be to make the attachment a global static. You set it on driver-entry, and you drop it on driver-exit.

You could technically re-create the attachment on each call, but the docs state that the attachment must not be dropped if there are outstanding allocations. So the intention really was that the attachment is not used in that style.

Lastly, I recommend writing your own bridge for the driver-usecase. global.rs is a rather small implementation and you can adopt it to your use-case with little effort. If you then have a solution you are happy with, I'd be glad to merge something suitable for UEFI drivers.