From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Wed, 29 May 2019 12:09:43 +0200 Subject: [U-Boot] [PATCH 0/2] efi_loader: implement deprecated Unicode collation protocol In-Reply-To: References: <20190516173456.27651-1-xypron.glpk@gmx.de> <20190524010200.GD28505@linaro.org> <1e256d92-9366-bd7e-6d28-b8ba68503374@gmx.de> Message-ID: <3ab144dc-e9c0-35d3-507a-bcb961b4967a@csgraf.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 24.05.19 15:30, Peter Robinson wrote: > On Fri, May 24, 2019 at 6:19 AM Heinrich Schuchardt wrote: >> On 5/24/19 3:02 AM, AKASHI Takahiro wrote: >>> Heinrich, >>> >>> On Thu, May 16, 2019 at 07:34:54PM +0200, Heinrich Schuchardt wrote: >>>> In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2 >>>> language codes existed. This protocol is not part of the UEFI specification >>>> any longer. Unfortunately it is required to run the UEFI Self Certification >>>> Test (SCT) II, version 2.6, 2017. So we implement it here for the sole >>>> purpose of running the SCT. It can be removed once a compliant SCT is >>>> available. >>> I remember that Alex always rejected this kind of patch, saying >>> that an upstream (SCT in this case) should be fixed in the first place. >>> >>> Do you want to change this policy? >>> (I'm just asking.) >> I am using SCT a lot to test my patches. I want to be able to run the >> tests on the final code. > Wouldn't it be better to patch/fork the upstream SCT that blindly > pulling in obsolete code that is basically already dead? > >> I have raised a ticket for upstream SCT but did not see any reaction up >> to now. > Got a reference to the ticket? > >> Making this deprecated protocol a config option deselected by default is >> the most plausible solution to me. In the Kconfig comment I made it >> clear that this protocol is going to be removed when the SCT has been >> corrected. > I disagree, I think if it's obsolete not having the code in the first > case in the most plausible option IMO. Since it's hidden behind a default-n config option, I'd not be terribly opposed to it. I do agree that fixing SCT is the better path forward. Leif, how long do you think fixing this properly in SCT is going to take? Alex