From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.100, mailfrom: dandan.bi@intel.com) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by groups.io with SMTP; Mon, 08 Apr 2019 01:08:08 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2019 01:08:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,324,1549958400"; d="scan'208,217";a="147423139" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by FMSMGA003.fm.intel.com with ESMTP; 08 Apr 2019 01:08:07 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Apr 2019 01:08:07 -0700 Received: from shsmsx105.ccr.corp.intel.com (10.239.4.158) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Apr 2019 01:08:06 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.92]) by SHSMSX105.ccr.corp.intel.com ([169.254.11.25]) with mapi id 14.03.0415.000; Mon, 8 Apr 2019 16:08:03 +0800 From: "Dandan Bi" To: "afish@apple.com" , "devel@edk2.groups.io" , Laszlo Ersek CC: "Ni, Ray" , "Kinney, Michael D" , "Cetola, Stephano" , "Gao, Liming" , "Carsey, Jaben" , "Bi, Dandan" Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master Thread-Topic: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master Thread-Index: AQHU6TD7crMm0LUFO0y81GpIjBVQGqYpLjeAgACD84CAAF7xAIAABPUAgABfGoCAAGM/AIAAB2MAgABupgCAAEofgIAAD8KAgAAIOACABjEVQA== Date: Mon, 8 Apr 2019 08:08:03 +0000 Message-ID: <3C0D5C461C9E904E8F62152F6274C0BB40BB8401@SHSMSX104.ccr.corp.intel.com> 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> <5F352F8C-272F-45F4-9834-54ACE2C814FE@apple.com> In-Reply-To: <5F352F8C-272F-45F4-9834-54ACE2C814FE@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: dandan.bi@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_3C0D5C461C9E904E8F62152F6274C0BB40BB8401SHSMSX104ccrcor_" --_000_3C0D5C461C9E904E8F62152F6274C0BB40BB8401SHSMSX104ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Andrew for the summary. For now there is no objection for platform to use shell source build, so I= think I can remove the dependency of ShellBinPkg in all open platforms fir= stly. And I will delete ShellBinPkg if there is no need to publish shell binarie= s or after shell binaries have been uploaded with stable tag. If all think publish stable shell binaries is useful and need to upload th= em with stable tag. Liming, could you help work out the process for shell binaries publish wi= th each edk2 stable tag? Then we can follow the process to upload the binaries and remove ShellBinP= kg finally. Thanks, Dandan From: afish@apple.com [mailto:afish@apple.com] Sent: Friday, April 5, 2019 12:36 AM To: devel@edk2.groups.io; Laszlo Ersek Cc: Ni, Ray ; Kinney, Michael D ; Bi, Dandan ; Cetola, Stephano ; Gao, Liming ; Carsey, Jaben Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk= 2/master 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 stabl= e tag. If we go in this way, it means "build" requires network connection to down= load 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 Py= thon or the C compilers, that copies the binary. You need a network connect= ion to clone the git repo and to stay in sync with it. I guess you could mo= del that as a git submodule, or actually have a script that grabs the binar= y 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-comp= onent 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 pr= ojects that need the Shell should define how that works. I don't think we n= eed to define a generic solution for 3rd parties as I'd guess Red Hat and M= icrosoft probably already have tools and strategies to deal with cobbling t= ogether software from different packages. So I guess we should ask the maintainers of the ekd2 packages does the ver= sion of the Shell matter? If no then just pre-install a shell binary as par= t of the setup. If the version matters then we should look into doing somet= hing a little more fancy, and use the pre-installed shell binary as the fal= lback. Is there anyway to tell the Shell version from the Shell PE/COFF? One opti= on could be a build warning if the shell is old and just have the user manu= ally 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 down= load 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 binarie= s if non of the edk2 packages require that feature. Thanks, Andrew Fish Thanks, Laszlo --_000_3C0D5C461C9E904E8F62152F6274C0BB40BB8401SHSMSX104ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Andrew for the summary.<= /o:p>

 

For now there is no objection for pl= atform to use shell source build, so I think I can remove the dependency of= ShellBinPkg in all open platforms firstly.

And I will delete ShellBinPkg if the= re is no need to publish shell binaries or after shell binaries have been u= ploaded with stable tag.

 

If all think publish stable shell bi= naries is useful and need to upload them with stable tag.

Liming,  could you help work ou= t the process for shell binaries publish with each edk2 stable tag?

Then we can follow the process to up= load the binaries and remove ShellBinPkg finally.

 

Thanks,

Dandan

 

From: afish@apple.com [mailto:afish= @apple.com]
Sent: Friday, April 5, 2019 12:36 AM
To: devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com> Cc: Ni, Ray <ray.ni@intel.com>; Kinney, Michael D <michael= .d.kinney@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Cetola, St= ephano <stephano.cetola@intel.com>; Gao, Liming <liming.gao@intel.= com>; Carsey, Jaben <jaben.carsey@intel.com>
Subject: Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg f= rom edk2/master

 

 



On Apr 4, 2019, at 9:06 AM, Laszlo Ersek <lersek@redhat.com> wrote:<= /p>

 

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 Apr 3, 2019, at= 8:42 PM, Ni, Ray <ray.ni@i= ntel.com> wrote:

Mike, Laszlo,
It's a good idea to store the shell binaries into the assets of each stabl= e tag.

If we go in this way, it means "build" requires network connecti= on 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 Py= thon or the C compilers, that copies the binary. You need a network connect= ion to clone the git repo and to stay in sync with it. I guess you could mo= del that as a git submodule, or actually have a script that grabs the binary you want from a remote system, and fa= ll 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-comp= onent 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 pr= ojects that need the Shell should define how that works. I don't think we n= eed to define a generic solution for 3rd parties as I'd guess Red Hat and M= icrosoft probably already have tools and strategies to deal with cobbling together software from different pac= kages.  

So I guess we should ask the maintainers of the ekd2 packages does the ver= sion of the Shell matter? If no then just pre-install a shell binary as par= t of the setup. If the version matters then we should look into doing somet= hing 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 opti= on could be a build warning if the shell is old and just have the user manu= ally 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 rai= ls. 

 

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 bina= ry that people can download from the web, and the hash that proves it is th= e version you think it is. Some instructions on how build a bootable USB ke= y would be useful too. 

3) We don't really need to solve the problem of a b= uild system and binaries if non of the edk2 packages require that feature.&= nbsp;

 

Thanks,

 

Andrew Fish



Thanks,
Laszlo

 

--_000_3C0D5C461C9E904E8F62152F6274C0BB40BB8401SHSMSX104ccrcor_--