public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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

  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