From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (NAM04-MW2-obe.outbound.protection.outlook.com [40.92.46.98]) by mx.groups.io with SMTP id smtpd.web10.18952.1683256434992657274 for ; Thu, 04 May 2023 20:13:55 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@outlook.com header.s=selector1 header.b=VYzoieSR; spf=pass (domain: outlook.com, ip: 40.92.46.98, mailfrom: spbrogan@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BdzqdT30T/82l4Flx8vH4JWHbIqDsAqM+2CvYcIRWCFIRtlY7yp6SFVTT1GvdGJfCR5EuasGN/ekEVhY+pThAg490akT7fGA1hVoCj9+j+GC9qBs8THlDfapQiyfqj+67/iibbBoSPG9PwxDeWDzHTzKzJGWRT26xntoC4bk7vPaSKqlIqpY+8cu3B11IMo1LrfU78rowIJ260EySURUoB5PJsRXezJBwmitt1tWUpSTBew0tqAAqKOU7NdU+SovnUExRQ3vW+QVDvaSLmri1LiNZDaNToqdKw4/bgC0qg4TMUiF6jt41xiLmaZgkhkPPzFrXlEGSunG3hg72urEog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kFgluNviwjcD4z/tGLzTdW25yJRG2C0T/P7orx32YSs=; b=jr2H/6nMlYz9gon/Kff3chnAT98wb5eZfgT+b3t0vyhjbUcar8T2hX+PtZfc6mZm8WkUp/fYlkkpmZBgr4KhJrDr66vJU+UzUAOHPT4Z0ErzYFII3ZWrpFZtsIzc8MYF7L+WD9tW7PeDj1NhDKajiZ8OtsAaXE1Y6oR2OC4qy0DQMNR8YBF3LHulENJaOw3qBWFD/PJpYPHYOAFVy+X3aDof/u969hn2d/8gy1p1vjdUCY0/hOfxaiC15MdnmJHXzAHo/yypQsqLVoiZldgbbTEc4BKAaTZ9CwMliIjSb7Je5V7vMpp//6L4xZYhwb5BIE2vb0fsNtZ9PVkLyq5FJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kFgluNviwjcD4z/tGLzTdW25yJRG2C0T/P7orx32YSs=; b=VYzoieSRH+q/P+B/u0PhQjtLU9QgVK/6AZYqJxC1UA0rAU3NJ145v6CotfGLcyHlZEoahIa6ajBf4uWbdnxaSK2PX90xvMz79xeav/ta7RA5fXl/WGNfnJ54ju5ltWUeNZCTkuCInm0n7IB6mqYQ8buQlsX9IEMN936rqwXrEwtheYdW2biZMKF9G68roYCvhgEe4EH9Igueu4252bBSkj2xwsKP3dGNrzpM1qF6HF3D98cSJxgJ1XY6jfb5UjmwvqAO8/R994nx8ecUmNW0yr4ICJFUAdIXkn5Y1cXVCzP8t6YfOOf2Joo6QX9Xbld2qb2m1J/b5TXRVfAQ0uhzQg== Received: from BY3PR19MB4900.namprd19.prod.outlook.com (2603:10b6:a03:354::11) by DS7PR19MB6351.namprd19.prod.outlook.com (2603:10b6:8:95::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.22; Fri, 5 May 2023 03:13:53 +0000 Received: from BY3PR19MB4900.namprd19.prod.outlook.com ([fe80::358d:ef31:7691:6ec4]) by BY3PR19MB4900.namprd19.prod.outlook.com ([fe80::358d:ef31:7691:6ec4%6]) with mapi id 15.20.6387.008; Fri, 5 May 2023 03:13:53 +0000 Message-ID: Date: Thu, 4 May 2023 20:13:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [edk2-devel] OvmfPkg PlatformCI: Should iasl dependency be updated from 20190215.0.0 ? To: Gerd Hoffmann Cc: devel@edk2.groups.io, rebecca@bsdio.com, Ard Biesheuvel , Jiewen Yao , Jordan Justen , Sean Brogan , Michael Kubacki , Michael D Kinney , Liming Gao References: <5970efe0-b520-f92d-db2f-6ed809ce4e55@bsdio.com> From: "Sean" In-Reply-To: X-TMN: [EgHueYkYSdJeU/eBCCz7x36SsTqf3MkO] X-ClientProxiedBy: MW2PR16CA0071.namprd16.prod.outlook.com (2603:10b6:907:1::48) To BY3PR19MB4900.namprd19.prod.outlook.com (2603:10b6:a03:354::11) Return-Path: spbrogan@outlook.com X-Microsoft-Original-Message-ID: <14fd16b1-f40c-37b3-660f-8de34c8cb7e2@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY3PR19MB4900:EE_|DS7PR19MB6351:EE_ X-MS-Office365-Filtering-Correlation-Id: 88772803-cc3e-41f9-ceac-08db4d16c105 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 79hNYmHZ5DktNkk3Oj87vfDLkWCb9JOGvXyWhGNgia3CCGXIBR4ElcLtTRH0xJw3peN8zwoyy0iwh5jFlHEL7men0K6iuctuoyeB24ZoKjxK9kMfvqOAqLgQ8nlkWidVYpL7U02a5/25O9d8ZdmgGN7zVgHiYP/mpBep5Ravbh6Du20j3r+SNTTz2kwr+ABxI6eyFLs9Y+G8z0Zkea+4i2SZnqrwKqEXJYnwV+VbQneTu32vTU9xoEkWFLZPBRzMAuDG41k5yEOn3fFb+sydGM8CKb4tqNpcAWG+b8BKyWnUuy6QVYCl4Fj4xQpjHB+PNl1aCD/t+Pn8bTMx1B062nrcmWX43kBpl4X1nUjvqg+lCq9Ao5M2r5W3Ni+WaNytOgp7BYGpLe8YBn55fBxLBOQ1oHiXAL4tvNP6SeBnYfgcN2ojRkWP7jWzjlIMDu3VjWy5TBskS/IWm/wDNdDBiY0aEzEbBbvj0oiZRcCaIkiF9C1cUBhiRrpeUAAe4rGMIEa+3Nor7Zo8mJy5JrW8m57MrMYQHvt3WiPyTBuAB4xIkAPFqJwrkvbwVdBgFsimM5soJlOpp0hk84Yb67n/QHj3O3ESNchnAneGoK7NX/OmMvXge6Kih+eOtTMRlCje X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MHlIOVhSMEhYNVEvbEJOckRqc1UvSFk3N3NpMDFzaGJQR3pjZmN6RnBpVUxC?= =?utf-8?B?RTUwUFUwaHFINXJmNjdadWFxRzRYdi9UakVoZDcyeGhoa1NsOWhEUGdYNGFR?= =?utf-8?B?Q1hHS0pGVkNPKzIzTkFDMW5rc0RoaFBDdGdWK1F4bWtKdFBrckZmL29tWlpH?= =?utf-8?B?K0xYd2Q3c0liNldxdW4wcVJvNGwxQmJFOUpvTDdMbkZtc0lPV3BVazRhQUkx?= =?utf-8?B?TE5LN0pUOWJkU3RkVlMzRXFOaFN4TEJGaEYxY0xsb3FJcDZUL0lMR2JOTUhz?= =?utf-8?B?YllxOEFuSCtlUzZ0NkE0Q1BXdHhJTHptdzRmeFhybzhqVmxYYUIrRi9PT3Q2?= =?utf-8?B?TkVIelU0VzdsZWJHRjNuaUhjc3dUT1dRaE1MUjlTNlBjQmFzSjQwaEpHL293?= =?utf-8?B?L0FGa2hOVE9jZEJrckdJS3YwSmovYkpXenVnQ0tRemYvMEZwN2p3aEdCbHJn?= =?utf-8?B?N3dPVnA5SjRvOWk2RG9PUkNGOTBnUG5RbGJldEs4TlhWSjUrMEFDbFJsQ2dE?= =?utf-8?B?N1NqS2xFWFl4c1dQY3NqK28weUNxdllBM2pxUW1oaitMSGNYUFAxN0ZuaVd4?= =?utf-8?B?UVR3N0JYYzd3WjI4WGtZVHdSU3pvQUFSNkl4TWpscEhVTXFtcUtGZTVwTDhK?= =?utf-8?B?WWQ5dUl0blVWR1RuSmJCTnFuSjNVVU0vcWo5WDhJekFUUDBtWElCR2ttTHJJ?= =?utf-8?B?clkvZXhINnBXbDlTTTBaTDF0eXhWRWRNam0yb0FrK3VmcE53YVRTSjFHdmcw?= =?utf-8?B?Rmh3bXI4ZUVob3BGQVlsNXNydnJXQmFyRE41STEwK0JmMXNRbGVieVBHR0wx?= =?utf-8?B?dzl3OXpudklIOENjMEpuaStNS3pBNk11dWFXc1g1cGxVWW1DdExtRngxaTBC?= =?utf-8?B?UlptVmFWdDRNN09KVWxuZFpPb0N3c3VsN3BubG1LYXJ4TG44NWhMZjFrQ3o4?= =?utf-8?B?QXBvb25PSXhxSXAwUkFBeW55VVZ3L0p2VTZCc3dwMlNyNUF2VDNWa05DWDU0?= =?utf-8?B?TG8yVWY5STRTVksrTTZjWk9wWDdHVlpqRzc3UUdoamV2WFRHaS81UHAyYlNl?= =?utf-8?B?KzJ5UkxmYU9hNk5naWFJZlUzZUM0WVlxRXZsRk1rVVlIQW54MXNWZ2xvdWg2?= =?utf-8?B?c3dKRzJrVlFxNCtHaE5hRlcxZ09UQ0gyZjhIWFNGNk4rWU45aFRnSVBjbzlh?= =?utf-8?B?K28wWFFHWElDWFVOV3dmcVRTeHVSaFJ6QjFQSVRScGxWQ21ZeE9UYVY2KzhG?= =?utf-8?B?R1UyVkhXSGhhOE1wdUlEMWZ1eldoRzRzeENacnFRZkhCNjF6eEU2dmpZZDZy?= =?utf-8?B?OWFpbkNHZmRwSHdUTUFnUm0rWUh6QzRwOG5ZUzNrN09xaGtnbVdqSW14N1hH?= =?utf-8?B?cVN4STd5R0JPZWtqVDJZVGFWbWtOL2U5OFZENmczd1d0OHNrWnoyZ3NJbGVu?= =?utf-8?B?bnA1QnBpNitEWjN2TnpHZUEvcnhxYkpXUEFNWmRhR2JVdWJucFhsLzQxZWw2?= =?utf-8?B?WTJQN1NTbGRTcyt5T2E1QmZ1dTlGOHh2enN1U0h6cXBjVDdWbHBtV1hxQTFI?= =?utf-8?B?cDhSQ2lFbkpYZzhMbU1YZ21pcEs5aWNKaG91WFo3Z0VURWcveEZScXFNSTVQ?= =?utf-8?B?L3hQVHZvNXRJcnc1L0pJOFFPenRiZVE9PQ==?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88772803-cc3e-41f9-ceac-08db4d16c105 X-MS-Exchange-CrossTenant-AuthSource: BY3PR19MB4900.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 May 2023 03:13:53.4183 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR19MB6351 Content-Type: multipart/alternative; boundary="------------OL4LQ5layX0uGDfaQ5WuQ3cU" Content-Language: en-US --------------OL4LQ5layX0uGDfaQ5WuQ3cU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/3/2023 10:56 PM, Gerd Hoffmann wrote: > Hi, > >> I agree the iasl dependency for CI has not been managed consistently.   When >> all of the CI was setup we decided that iasl should be controlled by the >> platform and thus EmulatorPkg, ArmVirt, and OVMF have their own extdep. >> This gives those platforms control to rev their version as necessary for >> their platform.   We have found it very common in platform development for >> platforms to have different required versions of iasl.exe. > Are there cases where /old/ iasl versions are required? Yes.  On the commercial PC side we see this a lot.  Given how much ASL is in modern PCs it is very common for a platform's ASL code to not compile with the latest version.  That product and by extension, the ASL code, is often supported for 5+ years and then if you add on that the ASL compiler was probably already a year old at initial release that means the compiler can often be pretty old.  Additionally for those building brand new products that are using new capabilities in ACPI, they often need the newest version and can't wait for the distro package repository to pick up.  As a outsider/consumer of Linux, we have definitely had pain caused by the distro's default/available version.  For the Edk2 repo I can remember a lot of challenges around python 2 and 3 and versions and the various distro's package management. Additionally, for CI we want to drive consistency between Windows and Linux.  We want visibility into versions used and reproducibility.   Depending on distro package management make this significantly harder. EmulatorPkg, ArmVirtPkg, and OVMF could all opt into using the "scope" (edk2/Readme.md at master · tianocore/edk2 · GitHub ) that would leverage the Core CI's version of iasl so that they don't need to manage this but my initial hope was to showcase this capability and allow those "platforms" some of their own autonomy.  Obviously they haven't needed or used that yet so as we update Core CI we could also update those platforms to follow with the same extdep and version. > >> As for the feed.  Yes they are inconsistent.   We were moving away from a >> global nuget.org feed as it just didn't seem necessary to push to >> nuget.org.  But now we are evaluating ways to move entirely away from >> nuget.  Nuget.exe worked pretty well for Windows development and our initial >> use cases but has definitely created a headache on Linux, MacOS and other. >> There really isn't a generic package management solution that is supported >> cross platform that has free/high quality/secure hosting.  If anyone has >> ideas please share. > On linux / macos / *bsd there is usually no need to create your own > package management. Standard stuff like iasl / nasm is available as > linux distro package / bsd ports collection package. > > Usually you can't pick specific versions. Usually this isn't a big > issue though, unless you are using an older distro (such as ubuntu 18.04 > we used for CI before switching to containers) and need a recent version. > > take care, > Gerd > --------------OL4LQ5layX0uGDfaQ5WuQ3cU Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 5/3/2023 10:56 PM, Gerd Hoffmann wrote:
  Hi,


I agree the iasl dependency for CI has not been managed consistently.   When
all of the CI was setup we decided that iasl should be controlled by the
platform and thus EmulatorPkg, ArmVirt, and OVMF have their own extdep. 
This gives those platforms control to rev their version as necessary for
their platform.   We have found it very common in platform development for
platforms to have different required versions of iasl.exe.

Are there cases where /old/ iasl versions are required?

Yes.  On the commercial PC side we see this a lot.  Given how much ASL is in modern PCs it is very common for a platform's ASL code to not compile with the latest version.  That product and by extension, the ASL code, is often supported for 5+ years and then if you add on that the ASL compiler was probably already a year old at initial release that means the compiler can often be pretty old.  Additionally for those building brand new products that are using new capabilities in ACPI, they often need the newest version and can't wait for the distro package repository to pick up.  As a outsider/consumer of Linux, we have definitely had pain caused by the distro's default/available version.  For the Edk2 repo I can remember a lot of challenges around python 2 and 3 and versions and the various distro's package management.

Additionally, for CI we want to drive consistency between Windows and Linux.  We want visibility into versions used and reproducibility.   Depending on distro package management make this significantly harder. 

EmulatorPkg, ArmVirtPkg, and OVMF could all opt into using the "scope" (edk2/Readme.md at master · tianocore/edk2 · GitHub) that would leverage the Core CI's version of iasl so that they don't need to manage this but my initial hope was to showcase this capability and allow those "platforms" some of their own autonomy.  Obviously they haven't needed or used that yet so as we update Core CI we could also update those platforms to follow with the same extdep and version.  



As for the feed.  Yes they are inconsistent.   We were moving away from a
global nuget.org feed as it just didn't seem necessary to push to
nuget.org.  But now we are evaluating ways to move entirely away from
nuget.  Nuget.exe worked pretty well for Windows development and our initial
use cases but has definitely created a headache on Linux, MacOS and other. 
There really isn't a generic package management solution that is supported
cross platform that has free/high quality/secure hosting.  If anyone has
ideas please share.

On linux / macos / *bsd there is usually no need to create your own
package management.  Standard stuff like iasl / nasm is available as
linux distro package / bsd ports collection package.

Usually you can't pick specific versions.  Usually this isn't a big
issue though, unless you are using an older distro (such as ubuntu 18.04
we used for CI before switching to containers) and need a recent version.

take care,
  Gerd
--------------OL4LQ5layX0uGDfaQ5WuQ3cU--