From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.93, mailfrom: liming.gao@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by groups.io with SMTP; Mon, 15 Apr 2019 07:58:17 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Apr 2019 07:58:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,354,1549958400"; d="scan'208,217";a="337651814" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga006.fm.intel.com with ESMTP; 15 Apr 2019 07:58:16 -0700 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Apr 2019 07:58:16 -0700 Received: from shsmsx105.ccr.corp.intel.com (10.239.4.158) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Apr 2019 07:58:16 -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, 15 Apr 2019 22:58:12 +0800 From: "Liming Gao" To: "Bi, Dandan" , "afish@apple.com" , "devel@edk2.groups.io" , Laszlo Ersek , "ard.biesheuvel@linaro.org" CC: "Ni, Ray" , "Kinney, Michael D" , "Cetola, Stephano" , "Carsey, Jaben" , "Gao, Liming" 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: AQHU6TD7uj8LDCepRUudSxMeotd+4qYpLjeAgACD84CAAF7xAIAABPUAgABfGoCAAGM/AIAAB2MAgABupgCAAEofgIAAD8KAgAAIOACABbtXgIAL9yQA Date: Mon, 15 Apr 2019 14:58:12 +0000 Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14E427CCC@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> <3C0D5C461C9E904E8F62152F6274C0BB40BB8401@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <3C0D5C461C9E904E8F62152F6274C0BB40BB8401@SHSMSX104.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDE2YzYwNWItMDAxYi00MDAxLWE0YWQtNTg0NWJmMGVmODkwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiWHhLWVZYNnU2WXorTFFoZVN3cFR0SSsrUGZcL203V3JFeUJSNlBoWFR5dUlkcTBSc3NnYjE0bWdMblVyRHVpQ1IifQ== dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4A89E2EF3DFEDB4C8BFDE51014F606A14E427CCCSHSMSX104ccrcor_" --_000_4A89E2EF3DFEDB4C8BFDE51014F606A14E427CCCSHSMSX104ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ard: I see IA32/X64 Shell binary has been updated for 201903 stable tag. But,= ARM/ARCH64 version shell binary is not updated. Could you upload new versi= on binaries? Then, I can upload them into 2019 stable tag Assets. Thanks Liming From: Bi, Dandan Sent: Monday, April 8, 2019 4:08 PM 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 edk= 2/master 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, Danda= n >; 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_4A89E2EF3DFEDB4C8BFDE51014F606A14E427CCCSHSMSX104ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ard:

  I see IA32/X64= Shell binary has been updated for 201903 stable tag. But, ARM/ARCH64 versi= on shell binary is not updated. Could you upload new version binaries? Then, I can upload them into 2019 stable tag Assets.=

 

Thanks

Liming

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

 

Thanks Andrew for the= summary.

 

For now there is no o= bjection for platform to use shell source build, so I think I can remove th= e dependency of ShellBinPkg in all open platforms firstly.

And I will delete She= llBinPkg if there is no need to publish shell binaries or after shell binar= ies have been uploaded with stable tag.

 

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

Liming,  could y= ou help work out the process for shell binaries publish with each edk2 stab= le tag?

Then we can follow th= e process to upload 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<= /a>>
Cc: Ni, Ray <ray.ni@intel.co= m>; Kinney, Michael D <michael.d.kinney@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Cetola, Stephano <stephano.cetola@intel.co= m>; Gao, Liming <liming.g= ao@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, La= szlo Ersek <lersek@redhat.com&g= t; 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 = Apr 3, 2019, at 8:42 PM, Ni, Ray <ray.ni@intel.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 phas= e
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 d= iscussion off the rails. 

 

1) It seems like that for edk2= folks are happy with build form source. 

2)I agree it would useful to h= ave 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 bu= ild a bootable USB key would be useful too. 

3) We don't really need to sol= ve the problem of a build system and binaries if non of the edk2 packages r= equire that feature. 

 

Thanks,

 

Andrew Fish<= /p>

 

Thanks,
Laszlo

 

--_000_4A89E2EF3DFEDB4C8BFDE51014F606A14E427CCCSHSMSX104ccrcor_--