public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Marvin Häuser" <mhaeuser@posteo.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
	Pedro Falcato <pedro.falcato@gmail.com>
Subject: Re: [PATCH edk2-platforms 1/4] Ext4Pkg: Use depex for unicode collation protocols
Date: Fri, 17 Feb 2023 14:05:23 +0000	[thread overview]
Message-ID: <8AFBCC5C-C28B-4F57-9359-99CF24D42322@posteo.de> (raw)
In-Reply-To: <20230217111200.1293369-1-ardb@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

Hi Ard,

Thank you! Is "1/4" a mistake or did I miss the other 3? :)
Comments inline.

> On 17. Feb 2023, at 12:12, Ard Biesheuvel <ardb@kernel.org> wrote:
> 
> The Unicode collation protocols, however, are different: loading the
> driver will fail if neither of those are present. So they are not
> TO_START protocols, and they need to be mentioned in the DEPEX so that
> the DXE core will not dispatch the driver before the producers of the
> prerequisite protocols have been dispatched. Also, mark them as
> SOMETIMES_CONSUMES, as only one of the two is required.

Right. FatPkg solves this by probing for the protocol in Start() [1], which should guarantee that all entry points have been executed first, right? I'd prefer a universal and consistent solution to the issue and this looks fine, honestly.

[1]
https://github.com/tianocore/edk2/blob/02fcfdce1e5ce86f1951191883e7e30de5aa08be/FatPkg/EnhancedFatDxe/Fat.c#L381
https://github.com/tianocore/edk2/blob/02fcfdce1e5ce86f1951191883e7e30de5aa08be/FatPkg/EnhancedFatDxe/Fat.inf#L19

> -  MODULE_TYPE                    = UEFI_DRIVER
> +  MODULE_TYPE                    = DXE_DRIVER

Is it not unidiomatic to use the UEFI Driver Binding model (UEFI) in a DXE driver (UEFI PI)?

> +[Depex]
> +  gEfiUnicodeCollationProtocolGuid OR gEfiUnicodeCollation2ProtocolGuid

Hmm, this will have the side effect that Ext4Dxe may load before (some of) the architectural protocols, right (modulo implicit dependencies via the UC protocols)? This would need some careful analysis, or we need to add all of the architectural protocols to preserve the old behaviour.

Best regards,
Marvin

[-- Attachment #2: Type: text/html, Size: 2723 bytes --]

  reply	other threads:[~2023-02-17 14:05 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 [this message]
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
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=8AFBCC5C-C28B-4F57-9359-99CF24D42322@posteo.de \
    --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