From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.1204.1676656887178151060 for ; Fri, 17 Feb 2023 10:01:27 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=QohH69Nj; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 873EC61F26 for ; Fri, 17 Feb 2023 18:01:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59511C43444 for ; Fri, 17 Feb 2023 18:01:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676656885; bh=OIoXNAqdvG9llRLdzaxdqs1gPMv+zqoMn/akEWyKRn0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QohH69NjTjXXIxHBZaM3gD0NIaptCfJxdudAb7IDlZaoqno0XNquDLgPRfDjm6VNG zCaEEcNWpYP/8NogHMrx2doqsJYsprc/bSQ5muW7Wk0mlDrPX8fhEwURU8kZM9eBVA O8SkWm6o2GHsIylHv6iArRzRyQHpEvoLw/4/+1gftIC2cZCYhfmcU8RygM5FoPqRZW 4N/5q2BEJN2qYCL/wu4+XOOOlMrILIBmOPMmTG83RCWBw2qhgBzAGK9IfCoMCOqxEs RsfrqjBtyz/EORcAB6eptWLHyCJYRG5rJKeIzJmOZWDNtyrn5EzJq4gQ8P3+CWEq7H qIaBhoBAMTYKQ== Received: by mail-lf1-f43.google.com with SMTP id t8so2325298lft.11 for ; Fri, 17 Feb 2023 10:01:25 -0800 (PST) X-Gm-Message-State: AO0yUKUGE+CfuuhPQ/eQvJpGfXoIqRMdaNvi4Rs0LAJ0dl/JW0bAxtgE BJ5xfswld47awdKIM3F+Qjl7navSiyA9W1ZgDNo= X-Google-Smtp-Source: AK7set+C9mSLXQe3gvVrJ/4WfugNFj9yXJq3xDdK895Jaik+ZazhIa6zen4flJShNIP5kDiiPbr1m3Sah4Xqk4y4AT0= X-Received: by 2002:ac2:59dd:0:b0:4d5:ca42:e43e with SMTP id x29-20020ac259dd000000b004d5ca42e43emr607987lfn.7.1676656883397; Fri, 17 Feb 2023 10:01:23 -0800 (PST) MIME-Version: 1.0 References: <2DE5E6BC-4AAE-4E31-91E2-B47B2F93DA43@posteo.de> <95DFC869-4A0A-4536-99F6-B8CDA151D433@posteo.de> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 17 Feb 2023 19:01:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH edk2-platforms 1/4] Ext4Pkg: Use depex for unicode collation protocols To: Pedro Falcato Cc: =?UTF-8?Q?Marvin_H=C3=A4user?= , edk2-devel-groups-io Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 17 Feb 2023 at 18:31, Pedro Falcato wrote= : > > On Fri, Feb 17, 2023 at 3:38 PM Marvin H=C3=A4user w= rote: > > > > > > > On 17. Feb 2023, at 16:17, Ard Biesheuvel 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. > Indeed. I suspect this was moved into Start() rather than Supported() because the latter is called much more often by the driver model logic. However, given that we populate a global variable with a protocol pointer, we can simply skip this logic once we have managed to set it once.