Re: [edk2-devel] [PATCH edk2-platforms 1/4] Ext4Pkg: Use depex for unicode collation protocols

["Marvin Häuser" <mhaeuser@posteo.de>]

> On 17. Feb 2023, at 16:17, Ard Biesheuvel <ardb@kernel.org> wrote:
> 
> So the FAT driver will happily load, but then fail in an obscure
> manner when being started on a controller handle, in a way that is
> indistinguishable (afict) from a partition that has not FAT file
> system in the first place.
> 
> So it doesn't look fine to me at all, tbh. If the collation protocols
> are required, we should check for them in supported(), and make a lot
> of noise in a DEBUG build if the failure condition is an unexpected
> one, i.e., some additional protocol we dependent on (even though we
> pretend to be a UEFI driver)  does not exist.

Right, I meant the approach to rely on the UEFI Driver Binding handling to defer locating UC, not the exact implementation. Sounds good.

@Pedro What do you think?

> 
> Alternatively, we might defer installation of the driver binding
> protocol implementation to a callback on the collation protocol
> installation, but that seems like more work for the same result.

Agreed.

> I will +1 any solution that removes the DXE dispatcher entirely as a
> side effect, but unfortunately, that is not going to happen :-)

We will probably attempt something like this downstream at some point (we do not care about UEFI PI), so even more reason I dislike dependencies on its workings. In a lot of cases (like the architectural protocols), the dependency situation is much more simple than what Depex supports. I.e., the protocols often are unconditionally installed in the entry point. Then we can just re-order the modules at FD build-time rather than relying on runtime code in the dispatcher. Complex dependencies, if they cannot be avoided, may be rewritten with events, not sure yet.

> We could depex on the UEFI driver prerequisites as well as the
> collation protocol ones, arguably retaining the UEFI_DRIVER status.

That's what I meant, yes, but I prefer the above solution myself.

Best regards,
Marvin