From: "Pedro Falcato" <pedro.falcato@gmail.com>
To: "Marvin Häuser" <mhaeuser@posteo.de>
Cc: Ard Biesheuvel <ardb@kernel.org>,
edk2-devel-groups-io <devel@edk2.groups.io>
Subject: Re: [edk2-devel] [PATCH edk2-platforms 1/4] Ext4Pkg: Use depex for unicode collation protocols
Date: Fri, 17 Feb 2023 17:31:28 +0000 [thread overview]
Message-ID: <CAKbZUD2WE+292phGWiWWm65Rv4ywG0EG2q5afxx24WJqPPEq6g@mail.gmail.com> (raw)
In-Reply-To: <95DFC869-4A0A-4536-99F6-B8CDA151D433@posteo.de>
On Fri, Feb 17, 2023 at 3:38 PM Marvin Häuser <mhaeuser@posteo.de> wrote:
>
>
> > 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.
Hi Ard, Marvin,
First of all, thank you for raising this issue and sending a patch. I
had been quietly following the thread while trying to get my ideas
straight.
>
> 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?
>
I think deferring the Unicode collation init to Start()/Supported() is
a good idea. I believe there's good value in keeping Ext4Dxe a
UEFI_DRIVER.
I was trying to come up with reasons why this would not work (in a
general UEFI-spec sense, not only in Tiano, but for instance if you
would ever want to plug this into i.e u-boot's EFI implementation).
As far as I can tell, there doesn't seem to be any? At least from a PI
PoV things should only get Start()'d in BDS right? And since other
PI-unaware implementations don't know what DXE or DXE_DRIVERs are,
it's not like that would fix those use cases.
> >
> > 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.
+1
--
Pedro
next prev parent reply other threads:[~2023-02-17 17:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 11:12 [PATCH edk2-platforms 1/4] Ext4Pkg: Use depex for unicode collation protocols Ard Biesheuvel
2023-02-17 14:05 ` Marvin Häuser
2023-02-17 14:29 ` [edk2-devel] " Ard Biesheuvel
2023-02-17 14:54 ` Marvin Häuser
2023-02-17 15:17 ` Ard Biesheuvel
2023-02-17 15:38 ` Marvin Häuser
2023-02-17 17:31 ` Pedro Falcato [this message]
2023-02-17 18:01 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKbZUD2WE+292phGWiWWm65Rv4ywG0EG2q5afxx24WJqPPEq6g@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox