From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=GuC0a/yT; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by groups.io with SMTP; Thu, 04 Apr 2019 09:36:19 -0700 Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x34GVr0F051825; Thu, 4 Apr 2019 09:36:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=j23fI/PyhHhzArXlJ8W6kL+G+u86jcfEVGUH3VGWCDs=; b=GuC0a/yTKc8NeNq6AQL2BOJDHtc+lbm8AjXXY13EiaaWfO2tQ3Bk/F+rvt8/RVPgHavv tDAmQ62YaYenbWB45CNRTb5BGM6zvJWF6bKvgWjW0XLbcRLdG0WHdWVQShaWgGCzFdZI JOGV8T4Skybeih3wHJ/i8bE30OP4HlIc+HXUwlxR1JAnWXaMz8CoOW9LBrdDcP/nkKev STxPsov2u62hqKOE6x8thUBJ5IJWktGbwHa4k1/c12r9y4F+XjptJBbFeoRf4y+vZ/Tm mnV6Jkw6OHlxwsCGLxKglUJz7aRuW6eAp0CPSJj1Pxl7OCpV/e2ocXL7Ricjy3y6LJ4f fA== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2rmg29yedj-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 04 Apr 2019 09:36:18 -0700 MIME-version: 1.0 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PPG006OA3GI7880@mr2-mtap-s01.rno.apple.com>; Thu, 04 Apr 2019 09:36:18 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PPG00F003E8RB00@nwk-mmpp-sz09.apple.com>; Thu, 04 Apr 2019 09:36:18 -0700 (PDT) X-Va-A: X-Va-T-CD: 08777febe38bb384cc57fda39d0586b7 X-Va-E-CD: d9b9ad8de82c93238b5cb6235c180f11 X-Va-R-CD: 1ab40ac838417d3a6569c88ce1c44cd5 X-Va-CD: 0 X-Va-ID: 9be7b5ee-af5c-4d84-b39b-1a616e7d0c0d X-V-A: X-V-T-CD: bf37c344c8485966b42248bc5fa11885 X-V-E-CD: d9b9ad8de82c93238b5cb6235c180f11 X-V-R-CD: 1ab40ac838417d3a6569c88ce1c44cd5 X-V-CD: 0 X-V-ID: 7650efa0-8802-4109-8c0f-11831418b71a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-04_09:,, signatures=0 Received: from [17.226.41.11] (unknown [17.226.41.11]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PPG001A93GHS040@nwk-mmpp-sz09.apple.com>; Thu, 04 Apr 2019 09:36:17 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: <5F352F8C-272F-45F4-9834-54ACE2C814FE@apple.com> Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master Date: Thu, 04 Apr 2019 09:36:14 -0700 In-reply-to: <6d7be3b2-c9c0-b543-ec49-e5b1701b2381@redhat.com> Cc: ray.ni@intel.com, Mike Kinney , "Bi, Dandan" , "Cetola, Stephano" , "Gao, Liming" , "Carsey, Jaben" To: devel@edk2.groups.io, Laszlo Ersek References: <3C0D5C461C9E904E8F62152F6274C0BB40BB5D6F@SHSMSX104.ccr.corp.intel.com> <9492a5a0-58fc-4e49-4645-0593aa758660@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C0C69A2@SHSMSX104.ccr.corp.intel.com> <82ac9c41-e12d-7287-74f2-d8bea4516280@redhat.com> <565232dc-a0ff-7b1b-3a7c-9c6db0b26969@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C0CCA8C@SHSMSX104.ccr.corp.intel.com> <2c9dd2e2-c261-4216-9541-26f7e4a63988@redhat.com> <6d7be3b2-c9c0-b543-ec49-e5b1701b2381@redhat.com> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-04_08:,, signatures=0 Content-type: multipart/alternative; boundary="Boundary_(ID_fIepKEhemHd7ZfxZxpMEmw)" --Boundary_(ID_fIepKEhemHd7ZfxZxpMEmw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Apr 4, 2019, at 9:06 AM, Laszlo Ersek wrote: > > On 04/04/19 17:10, Andrew Fish wrote: >> >> >>> On Apr 4, 2019, at 3:45 AM, Laszlo Ersek wrote: >>> >>> On 04/04/19 06:09, Andrew Fish wrote: >>>> >>>> >>>>> On Apr 3, 2019, at 8:42 PM, Ni, Ray wrote: >>>>> >>>>> Mike, Laszlo, >>>>> It's a good idea to store the shell binaries into the assets of each stable tag. >>>>> >>>>> If we go in this way, it means "build" requires network connection to download the >>>>> shell binary from the assets of a certain release. >>>>> Do you think it's acceptable? >>>>> >>>> >>>> Ray, >>>> >>>> The other option would be to have a configuration step, like installing Python or the C compilers, that copies the binary. You need a network connection to clone the git repo and to stay in sync with it. I guess you could model that as a git submodule, or actually have a script that grabs the binary you want from a remote system, and fall back to the local copy if you don't have a network connection. >>>> >>>> >>>>> Or we can separate the binary download and build into two phases so build phase >>>>> can be independent on network connection. >>>>> >>>>> Is there any known practice/solution for such requirement (stable sub-component binaries >>>>> needed by a production image generation)? >>>>> >>>> >>>> I think to some extent this kind of thing is driven by the customers build rules. Basically what the customer think of as their manifest of parts for software version X. >>> >>> I suggested PREBUILD because I took it as a given, from Mike's problem >>> statement, that "build" had to ensure, internally, the local >>> availability of the shell binary. >>> >>> If that's a not requirement, then IMO it's much better to leave it to >>> organizations to fetch the prerequisites of their platform builds. I'd >>> say that's out of scope for upstream edk2 -- if they need the shell >>> binary to be available off-line, at their build time, they can download >>> it earlier and cache it locally. >>> >> >> Laszlo, >> >> I guess for edk2 projects the maintainers own the manifest. So the edk2 projects that need the Shell should define how that works. I don't think we need to define a generic solution for 3rd parties as I'd guess Red Hat and Microsoft probably already have tools and strategies to deal with cobbling together software from different packages. >> >> So I guess we should ask the maintainers of the ekd2 packages does the version of the Shell matter? If no then just pre-install a shell binary as part of the setup. If the version matters then we should look into doing something a little more fancy, and use the pre-installed shell binary as the fallback. >> >> Is there anyway to tell the Shell version from the Shell PE/COFF? One option could be a build warning if the shell is old and just have the user manually update the shell if needed. > > As a co-maintainer under OvmfPkg and ArmVirtPkg, I prefer to build the > shell from source at all times, namely from the source code that is part > of the entire edk2 tree at a given commit / checkout. > > I don't see any possibility or desire for the virtual firmware packages > (RPMs) that I have a say in to consume/ship a pre-built UEFI shell binary. > > --*-- > > The reason I recommend for us (the TianoCore community) to offer the > shell as a prebuilt binary too, somewhere on the web, is because it > would help UEFI users (in the most general sense). > Laszlo, Sorry I might have taken the discussion off the rails. 1) It seems like that for edk2 folks are happy with build form source. 2)I agree it would useful to have a known good binary that people can download from the web, and the hash that proves it is the version you think it is. Some instructions on how build a bootable USB key would be useful too. 3) We don't really need to solve the problem of a build system and binaries if non of the edk2 packages require that feature. Thanks, Andrew Fish > Thanks, > Laszlo > > --Boundary_(ID_fIepKEhemHd7ZfxZxpMEmw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Apr 4,= 2019, at 9:06 AM, Laszlo Ersek <lersek@redhat.com> wrote:

On 04/04/19 17:10, Andrew Fish wrote:


On Apr 4, 2019, = at 3:45 AM, Laszlo Ersek <lersek@redhat.com> wrote:

On 04/04/19= 06:09, Andrew Fish wrote:


On Ap= r 3, 2019, at 8:42 PM, Ni, Ray <ray.ni@intel.com> wrote:

Mike, L= aszlo,
It's a good idea to store the shell binaries into the = assets of each stable tag.

If we go in this wa= y, it means "build" requires network connection to download the
shell binary from the assets of a certain release.
Do you = think it's acceptable?


Ray,

The other option would be to have = a configuration step, like installing Python or the C compilers, that copie= s the binary. You need a network connection to clone the git repo and to st= ay in sync with it. I guess you could model that as a git submodule, or act= ually have a script that grabs the binary you want from a remote system, an= d fall back to the local copy if you don't have a network connection. 

=
Or we can separate the = binary download and build into two phases so build phase
can = be independent on network connection.

Is there= any known practice/solution for such requirement (stable sub-component bin= aries
needed by a production image generation)?


I think to some extent this kin= d of thing is driven by the customers build rules. Basically what the custo= mer think of as their manifest of parts for software version X.

I suggested PREBUILD because I took it as a = given, from Mike's problem
statement, that "build" had to ens= ure, internally, the local
availability of the shell binary.<= br class=3D"">
If that's a not requirement, then IMO it's muc= h better to leave it to
organizations to fetch the prerequisi= tes of their platform builds. I'd
say that's out of scope for= upstream edk2 -- if they need the shell
binary to be availab= le off-line, at their build time, they can download
it earlie= r and cache it locally.


Laszlo,

I guess for edk2 projects the m= aintainers own the manifest. So the edk2 projects that need the Shell shoul= d define how that works. I don't think we need to define a generic solution= for 3rd parties as I'd guess Red Hat and Microsoft probably already have t= ools and strategies to deal with cobbling together software from different = packages.  

So I guess we should ask the = maintainers of the ekd2 packages does the version of the Shell matter? If n= o then just pre-install a shell binary as part of the setup. If the version= matters then we should look into doing something a little more fancy, and = use the pre-installed shell binary as the fallback. 

Is there anyway to= tell the Shell version from the Shell PE/COFF? One option could be a build= warning if the shell is old and just have the user manually update the she= ll if needed. 

As a co-m= aintainer under OvmfPkg and ArmVirtPkg, I prefer to build the
shell from source at all times, name= ly from the source code that is part
of the entire edk2 tree at a given commit / checkout.<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 1= 2px; font-style: normal; font-variant-caps: normal; font-weight: normal; le= tter-spacing: normal; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0p= x; text-decoration: none;" class=3D"">
I don't see any possibility or desire for the virtual firmware pac= kages
(RPMs) that I hav= e a say in to consume/ship a pre-built UEFI shell binary.

--*--

The reason I recommend for us (the TianoCore commun= ity) to offer the
she= ll as a prebuilt binary too, somewhere on the web, is because it
would help UEFI users (in the mos= t general sense).


Laszlo,

Sorry I might have taken the = discussion off the rails. 

1) It s= eems like that for edk2 folks are happy with build form source. 
=
2)I agree it would useful to have a known good binary that people can = download from the web, and the hash that proves it is the version you think= it is. Some instructions on how build a bootable USB key would be useful t= oo. 
3) We don't really need to solve the problem of a build= system and binaries if non of the edk2 packages require that feature. = ;

Thanks,

Andrew Fish

Thanks,
Laszlo


--Boundary_(ID_fIepKEhemHd7ZfxZxpMEmw)--