From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=148.163.143.35; helo=mx0b-002e3701.pphosted.com; envelope-from=brian.johnson@hpe.com; receiver=edk2-devel@lists.01.org Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (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 615A1211BA456 for ; Fri, 25 Jan 2019 12:29:14 -0800 (PST) Received: from pps.filterd (m0150244.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0PKPx7F026137; Fri, 25 Jan 2019 20:28:57 GMT Received: from g9t5008.houston.hpe.com (g9t5008.houston.hpe.com [15.241.48.72]) by mx0b-002e3701.pphosted.com with ESMTP id 2q85p9hujc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Jan 2019 20:28:57 +0000 Received: from g4t3433.houston.hpecorp.net (g4t3433.houston.hpecorp.net [16.208.49.245]) by g9t5008.houston.hpe.com (Postfix) with ESMTP id 57B1859; Fri, 25 Jan 2019 20:28:56 +0000 (UTC) Received: from [10.33.152.19] (bjj-laptop2.americas.hpqcorp.net [10.33.152.19]) by g4t3433.houston.hpecorp.net (Postfix) with ESMTP id CD5E145; Fri, 25 Jan 2019 20:28:54 +0000 (UTC) To: Laszlo Ersek , 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> From: "Brian J. Johnson" Message-ID: <4dfb6a1f-da8f-4141-8687-be968ff261a9@hpe.com> Date: Fri, 25 Jan 2019 14:28:54 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-25_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=757 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901250158 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: Fri, 25 Jan 2019 20:29:14 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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. -- Brian -------------------------------------------------------------------- "Occasionally get out of the office, the lab, the computer room, smell the flowers and take a look at the physical world around you." -- Rob Cook