From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B80CA21959CB2 for ; Mon, 28 Jan 2019 00:24:06 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5A3527F6A8; Mon, 28 Jan 2019 08:24:04 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-224.rdu2.redhat.com [10.10.120.224]) by smtp.corp.redhat.com (Postfix) with ESMTP id C6D0C51F33; Mon, 28 Jan 2019 08:23:57 +0000 (UTC) To: "Brian J. Johnson" , David Woodhouse , "Ni, Ray" , Gerd Hoffmann , "Richardson, Brian" Cc: Anthony Perard , "Justen, Jordan L" , "edk2-devel@lists.01.org" , Kevin O'Connor References: <734D49CCEBEEF84792F5B80ED585239D5BF6035C@SHSMSX104.ccr.corp.intel.com> <20181220064447.7eflwhm3t5upj7ds@sirius.home.kraxel.org> <734D49CCEBEEF84792F5B80ED585239D5BF6895F@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BFCEBF2@SHSMSX103.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D5BFCF8F8@SHSMSX103.ccr.corp.intel.com> <04736175-5976-8aff-ded1-e3bbbbaac679@redhat.com> <06825a8acc18a750c06675124373e40574e8e585.camel@infradead.org> <734D49CCEBEEF84792F5B80ED585239D5BFD28AE@SHSMSX103.ccr.corp.intel.com> <73ed780d136faa94f5e01b58762250e009b794f9.camel@infradead.org> <4dfb6a1f-da8f-4141-8687-be968ff261a9@hpe.com> From: Laszlo Ersek Message-ID: Date: Mon, 28 Jan 2019 09:23:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4dfb6a1f-da8f-4141-8687-be968ff261a9@hpe.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 28 Jan 2019 08:24:05 +0000 (UTC) Subject: Re: Drop CSM support in OvmfPkg? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 08:24:06 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/25/19 21:28, Brian J. Johnson wrote: > On 1/24/19 5:30 AM, Laszlo Ersek wrote: >> On 01/24/19 10:31, David Woodhouse wrote: >>> On Thu, 2019-01-24 at 01:48 +0000, Ni, Ray wrote: >>>> David, >>>> I think we got an agreement here to move CSM components in OvmfPkg. >>>> I prefer we firstly clone the required CSM components in OvmfPkg >>>> right no. >>>> Finally I can remove the IntelFrameworkModulePkg/IntelFrameworkPkg >>>> in one patch. >>>> (I say "finally" because OVMF CSM dependency is not the only case >>>> that prevent removing >>>> the two framework packages.) >>>> >>>> Would you like to do the clone? Or if you are busy, I can do that. >>> >>> I keep asking this question, I don't believe I've seen an >>> answer. Apologies if I've missed it. >> >> I think you haven't. And, I'm curious too. :) >> >> Thanks >> Laszlo >> >>> Is this code genuinely not going to continue to exist anywhere else in >>> the Intel ecosystem, any more? >>> >>> No TianoCore-based images from this point forth are ever going to even >>> have the option of supporting CSM? >>> >>> Unless some third party also chooses to fork the CSM support code and >>> keep it on for themselves? >>> > > In fall of 2017, Intel declared their intention to end legacy BIOS > support on their platforms by 2020. > > http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf > > > I believe they have stuck to this story at subsequent UEFI plugfests. Thank you! For me that answers the question. --*-- BTW, I'm glad slides 11, 17, 18 say "Remove user motivations to stick with BIOS: Improve experience with UEFI Secure Boot". It's incredible how many UEFI implementations do not offer any *real* BootOrder/Boot#### management even, not to mention the obscure hacks such as forcibly re-setting the first boot option to Windows, if it is installed etc. It's no surprise people rely on "shim" and "grub" (and other 3rd party boot loaders) more than ever -- they want to get out of the crappy platform firmware UI as soon as they can, and reach a UI they can actually control. Thanks, Laszlo