~philmd/edk2

10 3

[edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

Details
Message ID
<3C0D5C461C9E904E8F62152F6274C0BB40BB5D6F@SHSMSX104.ccr.corp.intel.com>
Sender timestamp
1554183529
DKIM signature
missing
Download raw message
Hi All,

ShellBinPkg is the remaining binary package in Edk2 repo.  We plan to delete ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2 repo.
Before the deletion, I will update the existing consumers in Edk2 and Edk2Platforms to use ShellPkg directly.

If you have any concern please raise here before mid-April . If there is no concern, I will create patches for this task after mid-April.

Bugzilla for this task:
https://bugzilla.tianocore.org/show_bug.cgi?id=1675


Thanks,
Dandan
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Laszlo Ersek <lersek@redhat.com>
Details
Message ID
<9492a5a0-58fc-4e49-4645-0593aa758660@redhat.com>
In-Reply-To
<3C0D5C461C9E904E8F62152F6274C0BB40BB5D6F@SHSMSX104.ccr.corp.intel.com> (view parent)
Sender timestamp
1554194956
DKIM signature
missing
Download raw message
On 04/02/19 07:38, Bi, Dandan wrote:
> Hi All,
> 
> ShellBinPkg is the remaining binary package in Edk2 repo.  We plan to delete ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2 repo.
> Before the deletion, I will update the existing consumers in Edk2 and Edk2Platforms to use ShellPkg directly.
> 
> If you have any concern please raise here before mid-April . If there is no concern, I will create patches for this task after mid-April.
> 
> Bugzilla for this task:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1675

(adding a few CC's)

I think we should not remove ShellBinPkg without a replacement *somehwere*.

A shell binary that is built from a validated edk2 tree, with a set of
library resolutions and PCD settings that are known to keep platform
dependencies *out* of the shell binary, is extremely useful.

IIRC, Andrew suggested earlier that we should treat the shell even as an
"OS", with better compatibility standards than we currently maintain.

I think we should only remove ShellBinPkg if we permanently offer a
separate download location instead, and we rebuild the shell binary from
"ShellPkg/ShellPkg.dsc" at every stable tag.

In that case, removing ShellBinPkg would indeed improve the edk2 tree,
in my opinion.

Thanks,
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Details
Message ID
<20190402091230.zmwcrwb6s55ontm5@bivouac.eciton.net>
In-Reply-To
<9492a5a0-58fc-4e49-4645-0593aa758660@redhat.com> (view parent)
Sender timestamp
1554196351
DKIM signature
missing
Download raw message
Hi Laszlo,

On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
> On 04/02/19 07:38, Bi, Dandan wrote:
> > Hi All,
> > 
> > ShellBinPkg is the remaining binary package in Edk2 repo.  We plan
> > to delete ShellBinPkg from edk2/master, and keep source ShellPkg
> > only in edk2 repo.
> > Before the deletion, I will update the existing consumers in Edk2
> > and Edk2Platforms to use ShellPkg directly.
> > 
> > If you have any concern please raise here before mid-April . If
> > there is no concern, I will create patches for this task after
> > mid-April.
> > 
> > Bugzilla for this task:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> 
> (adding a few CC's)
> 
> I think we should not remove ShellBinPkg without a replacement *somehwere*.
> 
> A shell binary that is built from a validated edk2 tree, with a set of
> library resolutions and PCD settings that are known to keep platform
> dependencies *out* of the shell binary, is extremely useful.

Agreed. However, I am not sure that accurately describes what we have
today.

> IIRC, Andrew suggested earlier that we should treat the shell even as an
> "OS", with better compatibility standards than we currently maintain.
> 
> I think we should only remove ShellBinPkg if we permanently offer a
> separate download location instead, and we rebuild the shell binary from
> "ShellPkg/ShellPkg.dsc" at every stable tag.

I think this sounds like an exellent improvement. When I saw the
patch, I did immediately think maybe I should start including them in
my Linaro releases. But if we could automate a build of binaries for
all supported architectures, and have a place to publish them, that
would be much better.

Best Regards,

Leif

> In that case, removing ShellBinPkg would indeed improve the edk2 tree,
> in my opinion.
> 
> Thanks,
> Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Details
Message ID
<a3abef3d458619073b7fb9aca1cb65b1921b377b.camel@linux.intel.com>
In-Reply-To
<20190402091230.zmwcrwb6s55ontm5@bivouac.eciton.net> (view parent)
Sender timestamp
1554204596
DKIM signature
missing
Download raw message
On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote:
> Hi Laszlo,
> 
> On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
> > On 04/02/19 07:38, Bi, Dandan wrote:
> > > Hi All,
> > > 
> > > ShellBinPkg is the remaining binary package in Edk2 repo.  We
> > > plan
> > > to delete ShellBinPkg from edk2/master, and keep source ShellPkg
> > > only in edk2 repo.
> > > Before the deletion, I will update the existing consumers in Edk2
> > > and Edk2Platforms to use ShellPkg directly.
> > > 
> > > If you have any concern please raise here before mid-April . If
> > > there is no concern, I will create patches for this task after
> > > mid-April.
> > > 
> > > Bugzilla for this task:
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> > 
> > (adding a few CC's)
> > 
> > I think we should not remove ShellBinPkg without a replacement
> > *somehwere*.
> > 
> > A shell binary that is built from a validated edk2 tree, with a set
> > of
> > library resolutions and PCD settings that are known to keep
> > platform
> > dependencies *out* of the shell binary, is extremely useful.
> 
> Agreed. However, I am not sure that accurately describes what we have
> today.
> 
> > IIRC, Andrew suggested earlier that we should treat the shell even
> > as an
> > "OS", with better compatibility standards than we currently
> > maintain.
> > 
> > I think we should only remove ShellBinPkg if we permanently offer a
> > separate download location instead, and we rebuild the shell binary
> > from
> > "ShellPkg/ShellPkg.dsc" at every stable tag.
> 
> I think this sounds like an exellent improvement. When I saw the
> patch, I did immediately think maybe I should start including them in
> my Linaro releases. But if we could automate a build of binaries for
> all supported architectures, and have a place to publish them, that
> would be much better.

One place to put them might be next to the stable releases on GitHub.
Sources are automatically packaged there, binaries can also be
uploaded, also automatically via CI. (Maybe it could also be used to
keep stable OVMF images? Would be nice for quick testing for people not
involved in UEFI development and not having these binaries available in
their OS repos, or having issues with 3rd party builds.)

> Best Regards,
> 
> Leif
> 
> > In that case, removing ShellBinPkg would indeed improve the edk2
> > tree,
> > in my opinion.
> > 
> > Thanks,
> > Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Laszlo Ersek <lersek@redhat.com>
Details
Message ID
<3c20917e-e091-354e-5c2d-09dc2a49ea0f@redhat.com>
In-Reply-To
<a3abef3d458619073b7fb9aca1cb65b1921b377b.camel@linux.intel.com> (view parent)
Sender timestamp
1554205509
DKIM signature
missing
Download raw message
On 04/02/19 13:29, Ryszard Knop wrote:
> On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote:
>> Hi Laszlo,
>>
>> On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
>>> On 04/02/19 07:38, Bi, Dandan wrote:
>>>> Hi All,
>>>>
>>>> ShellBinPkg is the remaining binary package in Edk2 repo.  We
>>>> plan
>>>> to delete ShellBinPkg from edk2/master, and keep source ShellPkg
>>>> only in edk2 repo.
>>>> Before the deletion, I will update the existing consumers in Edk2
>>>> and Edk2Platforms to use ShellPkg directly.
>>>>
>>>> If you have any concern please raise here before mid-April . If
>>>> there is no concern, I will create patches for this task after
>>>> mid-April.
>>>>
>>>> Bugzilla for this task:
>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
>>>
>>> (adding a few CC's)
>>>
>>> I think we should not remove ShellBinPkg without a replacement
>>> *somehwere*.
>>>
>>> A shell binary that is built from a validated edk2 tree, with a set
>>> of
>>> library resolutions and PCD settings that are known to keep
>>> platform
>>> dependencies *out* of the shell binary, is extremely useful.
>>
>> Agreed. However, I am not sure that accurately describes what we have
>> today.
>>
>>> IIRC, Andrew suggested earlier that we should treat the shell even
>>> as an
>>> "OS", with better compatibility standards than we currently
>>> maintain.
>>>
>>> I think we should only remove ShellBinPkg if we permanently offer a
>>> separate download location instead, and we rebuild the shell binary
>>> from
>>> "ShellPkg/ShellPkg.dsc" at every stable tag.
>>
>> I think this sounds like an exellent improvement. When I saw the
>> patch, I did immediately think maybe I should start including them in
>> my Linaro releases. But if we could automate a build of binaries for
>> all supported architectures, and have a place to publish them, that
>> would be much better.
> 
> One place to put them might be next to the stable releases on GitHub.
> Sources are automatically packaged there, binaries can also be
> uploaded, also automatically via CI. (Maybe it could also be used to
> keep stable OVMF images? Would be nice for quick testing for people not
> involved in UEFI development and not having these binaries available in
> their OS repos, or having issues with 3rd party builds.)

OVMF and ArmVirtQemu binaries are being bundled with upstream QEMU. The
series should be merged into QEMU 4.1.

The plan is to refresh the firmware binaries for each edk2 stable tag.

(It's also possible that users could benefit from synching QEMU and edk2
releases to an extent, similarly to how SeaBIOS and QEMU tend to be in
sync. (IIRC SeaBIOS tends to cut a new release shortly before QEMU, so
that QEMU can pick up the most recent release while it's fresh.) Anyway
this sub-topic is for the future.)

Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Details
Message ID
<ef9a96cbabbad217c29a8446520db4f3a9100973.camel@linux.intel.com>
In-Reply-To
<3c20917e-e091-354e-5c2d-09dc2a49ea0f@redhat.com> (view parent)
Sender timestamp
1554205829
DKIM signature
missing
Download raw message
On Tue, 2019-04-02 at 13:45 +0200, Laszlo Ersek wrote:
> On 04/02/19 13:29, Ryszard Knop wrote:
> > On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote:
> > > Hi Laszlo,
> > > 
> > > On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
> > > > On 04/02/19 07:38, Bi, Dandan wrote:
> > > > > Hi All,
> > > > > 
> > > > > ShellBinPkg is the remaining binary package in Edk2 repo.  We
> > > > > plan
> > > > > to delete ShellBinPkg from edk2/master, and keep source
> > > > > ShellPkg
> > > > > only in edk2 repo.
> > > > > Before the deletion, I will update the existing consumers in
> > > > > Edk2
> > > > > and Edk2Platforms to use ShellPkg directly.
> > > > > 
> > > > > If you have any concern please raise here before mid-April .
> > > > > If
> > > > > there is no concern, I will create patches for this task
> > > > > after
> > > > > mid-April.
> > > > > 
> > > > > Bugzilla for this task:
> > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> > > > 
> > > > (adding a few CC's)
> > > > 
> > > > I think we should not remove ShellBinPkg without a replacement
> > > > *somehwere*.
> > > > 
> > > > A shell binary that is built from a validated edk2 tree, with a
> > > > set
> > > > of
> > > > library resolutions and PCD settings that are known to keep
> > > > platform
> > > > dependencies *out* of the shell binary, is extremely useful.
> > > 
> > > Agreed. However, I am not sure that accurately describes what we
> > > have
> > > today.
> > > 
> > > > IIRC, Andrew suggested earlier that we should treat the shell
> > > > even
> > > > as an
> > > > "OS", with better compatibility standards than we currently
> > > > maintain.
> > > > 
> > > > I think we should only remove ShellBinPkg if we permanently
> > > > offer a
> > > > separate download location instead, and we rebuild the shell
> > > > binary
> > > > from
> > > > "ShellPkg/ShellPkg.dsc" at every stable tag.
> > > 
> > > I think this sounds like an exellent improvement. When I saw the
> > > patch, I did immediately think maybe I should start including
> > > them in
> > > my Linaro releases. But if we could automate a build of binaries
> > > for
> > > all supported architectures, and have a place to publish them,
> > > that
> > > would be much better.
> > 
> > One place to put them might be next to the stable releases on
> > GitHub.
> > Sources are automatically packaged there, binaries can also be
> > uploaded, also automatically via CI. (Maybe it could also be used
> > to
> > keep stable OVMF images? Would be nice for quick testing for people
> > not
> > involved in UEFI development and not having these binaries
> > available in
> > their OS repos, or having issues with 3rd party builds.)
> 
> OVMF and ArmVirtQemu binaries are being bundled with upstream QEMU.
> The
> series should be merged into QEMU 4.1.

Right, but for people stuck on older QEMU versions it'd be useful to
find everything conveniently in one place when googling "OVMF". And
there are quite a few of these versions in the wild: 
https://repology.org/project/qemu/versions

> The plan is to refresh the firmware binaries for each edk2 stable
> tag.
> 
> (It's also possible that users could benefit from synching QEMU and
> edk2
> releases to an extent, similarly to how SeaBIOS and QEMU tend to be
> in
> sync. (IIRC SeaBIOS tends to cut a new release shortly before QEMU,
> so
> that QEMU can pick up the most recent release while it's fresh.)
> Anyway
> this sub-topic is for the future.)
> 
> Thanks
> Laszlo

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Laszlo Ersek <lersek@redhat.com>
Details
Message ID
<812b93ca-d1a6-73cc-1f76-a27a9425673d@redhat.com>
In-Reply-To
<ef9a96cbabbad217c29a8446520db4f3a9100973.camel@linux.intel.com> (view parent)
Sender timestamp
1554209797
DKIM signature
missing
Download raw message
On 04/02/19 13:50, Ryszard Knop wrote:
> On Tue, 2019-04-02 at 13:45 +0200, Laszlo Ersek wrote:
>> On 04/02/19 13:29, Ryszard Knop wrote:
>>> On Tue, 2019-04-02 at 10:12 +0100, Leif Lindholm wrote:
>>>> Hi Laszlo,
>>>>
>>>> On Tue, Apr 02, 2019 at 10:49:16AM +0200, Laszlo Ersek wrote:
>>>>> On 04/02/19 07:38, Bi, Dandan wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> ShellBinPkg is the remaining binary package in Edk2 repo.  We
>>>>>> plan
>>>>>> to delete ShellBinPkg from edk2/master, and keep source
>>>>>> ShellPkg
>>>>>> only in edk2 repo.
>>>>>> Before the deletion, I will update the existing consumers in
>>>>>> Edk2
>>>>>> and Edk2Platforms to use ShellPkg directly.
>>>>>>
>>>>>> If you have any concern please raise here before mid-April .
>>>>>> If
>>>>>> there is no concern, I will create patches for this task
>>>>>> after
>>>>>> mid-April.
>>>>>>
>>>>>> Bugzilla for this task:
>>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
>>>>>
>>>>> (adding a few CC's)
>>>>>
>>>>> I think we should not remove ShellBinPkg without a replacement
>>>>> *somehwere*.
>>>>>
>>>>> A shell binary that is built from a validated edk2 tree, with a
>>>>> set
>>>>> of
>>>>> library resolutions and PCD settings that are known to keep
>>>>> platform
>>>>> dependencies *out* of the shell binary, is extremely useful.
>>>>
>>>> Agreed. However, I am not sure that accurately describes what we
>>>> have
>>>> today.
>>>>
>>>>> IIRC, Andrew suggested earlier that we should treat the shell
>>>>> even
>>>>> as an
>>>>> "OS", with better compatibility standards than we currently
>>>>> maintain.
>>>>>
>>>>> I think we should only remove ShellBinPkg if we permanently
>>>>> offer a
>>>>> separate download location instead, and we rebuild the shell
>>>>> binary
>>>>> from
>>>>> "ShellPkg/ShellPkg.dsc" at every stable tag.
>>>>
>>>> I think this sounds like an exellent improvement. When I saw the
>>>> patch, I did immediately think maybe I should start including
>>>> them in
>>>> my Linaro releases. But if we could automate a build of binaries
>>>> for
>>>> all supported architectures, and have a place to publish them,
>>>> that
>>>> would be much better.
>>>
>>> One place to put them might be next to the stable releases on
>>> GitHub.
>>> Sources are automatically packaged there, binaries can also be
>>> uploaded, also automatically via CI. (Maybe it could also be used
>>> to
>>> keep stable OVMF images? Would be nice for quick testing for people
>>> not
>>> involved in UEFI development and not having these binaries
>>> available in
>>> their OS repos, or having issues with 3rd party builds.)
>>
>> OVMF and ArmVirtQemu binaries are being bundled with upstream QEMU.
>> The
>> series should be merged into QEMU 4.1.
> 
> Right, but for people stuck on older QEMU versions it'd be useful to
> find everything conveniently in one place when googling "OVMF". And
> there are quite a few of these versions in the wild: 
> https://repology.org/project/qemu/versions

This doesn't seem to be a problem with the UEFI shell, but 'everything
conveniently in one place when googling "OVMF"' seems like a ship that
has sailed. To exaggerate a bit, when you google "Linux" or "QEMU", you
don't find everything in one place either. :)

For bleeding edge builds, people can (and do) already consume
<https://www.kraxel.org/repos/>. The point of bundling binaries, built
from the latest edk2-stableYYYYMM tag, with QEMU, is two-fold: (a)
following the tradition of bundling SeaBIOS, iPXE, and other
firmware(-level) binaries with QEMU, (b) allowing QEMU's own "make
check" to run UEFI helper apps in guests, without external dependencies
(both the platform firmware binaries and the UEFI app(s) are to be
tracked in the QEMU git tree).

NB purpose (a) is not universally accepted for QEMU either; there have
been ideas to move all of those firmware thingies out of QEMU. I'm
neutral on that longer-term question; for now, adding ArmVirtQemu and
OVMF binaries to the QEMU tree sticks with the tradition and improves
the availability of those firmware binaries.

That said, I'm not against offering OVMF builds via some kind of
TianoCore-owned CI. We should just be aware that adding more download
locations and calling them "official" will likely not eliminate any
builds we consider "unofficial". I'm undecided whether a new download
location will mitigate the confusion, or contribute to it.

Thanks,
Laszlo

>> The plan is to refresh the firmware binaries for each edk2 stable
>> tag.
>>
>> (It's also possible that users could benefit from synching QEMU and
>> edk2
>> releases to an extent, similarly to how SeaBIOS and QEMU tend to be
>> in
>> sync. (IIRC SeaBIOS tends to cut a new release shortly before QEMU,
>> so
>> that QEMU can pick up the most recent release while it's fresh.)
>> Anyway
>> this sub-topic is for the future.)
>>
>> Thanks
>> Laszlo
> 

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Details
Message ID
<734D49CCEBEEF84792F5B80ED585239D5C0C69A2@SHSMSX104.ccr.corp.intel.com>
In-Reply-To
<9492a5a0-58fc-4e49-4645-0593aa758660@redhat.com> (view parent)
Sender timestamp
1554257835
DKIM signature
missing
Download raw message

> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, April 2, 2019 4:49 PM
> To: Bi, Dandan <dandan.bi@intel.com>; edk2-devel@lists.01.org
> Cc: Cetola, Stephano <stephano.cetola@intel.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>; Carsey,
> Jaben <jaben.carsey@intel.com>
> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master
> 
> On 04/02/19 07:38, Bi, Dandan wrote:
> > Hi All,
> >
> > ShellBinPkg is the remaining binary package in Edk2 repo.  We plan to
> delete ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2
> repo.
> > Before the deletion, I will update the existing consumers in Edk2 and
> Edk2Platforms to use ShellPkg directly.
> >
> > If you have any concern please raise here before mid-April . If there is no
> concern, I will create patches for this task after mid-April.
> >
> > Bugzilla for this task:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> 
> (adding a few CC's)
> 
> I think we should not remove ShellBinPkg without a replacement
> *somehwere*.
> 
> A shell binary that is built from a validated edk2 tree, with a set of library
> resolutions and PCD settings that are known to keep platform dependencies
> *out* of the shell binary, is extremely useful.

I understand the concern.
Maybe a "Shell.dsc.inc" provided by ShellPkg which lists all library resolutions
, PCD settings and build options can be included by platform DSC to resolve such
dependency issue.

> 
> IIRC, Andrew suggested earlier that we should treat the shell even as an "OS",
> with better compatibility standards than we currently maintain.
> 
> I think we should only remove ShellBinPkg if we permanently offer a
> separate download location instead, and we rebuild the shell binary from
> "ShellPkg/ShellPkg.dsc" at every stable tag.

I do not quite understand. All other modules in edk2 repo are source-included by
OvmfPkg and daily commits directly generates new binaries for OvmfPkg.
I do not think we should have a different "binary-generation" model for
shell.

> 
> In that case, removing ShellBinPkg would indeed improve the edk2 tree, in
> my opinion.
> 
> Thanks,
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Laszlo Ersek <lersek@redhat.com>
Details
Message ID
<82ac9c41-e12d-7287-74f2-d8bea4516280@redhat.com>
In-Reply-To
<734D49CCEBEEF84792F5B80ED585239D5C0C69A2@SHSMSX104.ccr.corp.intel.com> (view parent)
Sender timestamp
1554286171
DKIM signature
missing
Download raw message
On 04/03/19 04:17, Ni, Ray wrote:
> 
> 
>> -----Original Message-----
>> From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of Laszlo
>> Ersek
>> Sent: Tuesday, April 2, 2019 4:49 PM
>> To: Bi, Dandan <dandan.bi@intel.com>; edk2-devel@lists.01.org
>> Cc: Cetola, Stephano <stephano.cetola@intel.com>; Kinney, Michael D
>> <michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>; Carsey,
>> Jaben <jaben.carsey@intel.com>
>> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master
>>
>> On 04/02/19 07:38, Bi, Dandan wrote:
>>> Hi All,
>>>
>>> ShellBinPkg is the remaining binary package in Edk2 repo.  We plan to
>> delete ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2
>> repo.
>>> Before the deletion, I will update the existing consumers in Edk2 and
>> Edk2Platforms to use ShellPkg directly.
>>>
>>> If you have any concern please raise here before mid-April . If there is no
>> concern, I will create patches for this task after mid-April.
>>>
>>> Bugzilla for this task:
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
>>
>> (adding a few CC's)
>>
>> I think we should not remove ShellBinPkg without a replacement
>> *somehwere*.
>>
>> A shell binary that is built from a validated edk2 tree, with a set of library
>> resolutions and PCD settings that are known to keep platform dependencies
>> *out* of the shell binary, is extremely useful.
> 
> I understand the concern.
> Maybe a "Shell.dsc.inc" provided by ShellPkg which lists all library resolutions
> , PCD settings and build options can be included by platform DSC to resolve such
> dependency issue.
> 
>>
>> IIRC, Andrew suggested earlier that we should treat the shell even as an "OS",
>> with better compatibility standards than we currently maintain.
>>
>> I think we should only remove ShellBinPkg if we permanently offer a
>> separate download location instead, and we rebuild the shell binary from
>> "ShellPkg/ShellPkg.dsc" at every stable tag.
> 
> I do not quite understand. All other modules in edk2 repo are source-included by
> OvmfPkg and daily commits directly generates new binaries for OvmfPkg.
> I do not think we should have a different "binary-generation" model for
> shell.

The standalone shell binary would not be offered for OVMF, but for all
possible UEFI platforms (physical and virtual alike).

People frequently turn to the UEFI shell for debugging UEFI issues on
their physical machines. Such users are generally not interested in
building the shell from source, just booting it as easily as possible.

Thanks,
Laszlo


>> In that case, removing ShellBinPkg would indeed improve the edk2 tree, in
>> my opinion.
>>
>> Thanks,
>> Laszlo
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Kinney, Michael D <michael.d.kinney@intel.com>
Details
Message ID
<E92EE9817A31E24EB0585FDF735412F5B9C774C3@ORSMSX112.amr.corp.intel.com>
In-Reply-To
<82ac9c41-e12d-7287-74f2-d8bea4516280@redhat.com> (view parent)
Sender timestamp
1554306560
DKIM signature
missing
Download raw message
Laszlo,

I think it makes sense to post validated shell binaries
with the edk2-stable tag releases.  GitHub does support
this when a release tag is made.

However, we would need to make it simple for a platform
to use a binary from that location.  We may need some
enhancements to pull in binary artifacts from different
locations to support a platform build that uses one or
more pre-built binaries.

Mike

> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Wednesday, April 3, 2019 3:10 AM
> To: Ni, Ray <ray.ni@intel.com>; Bi, Dandan
> <dandan.bi@intel.com>; edk2-devel@lists.01.org
> Cc: Cetola, Stephano <stephano.cetola@intel.com>;
> Kinney, Michael D <michael.d.kinney@intel.com>; Gao,
> Liming <liming.gao@intel.com>; Carsey, Jaben
> <jaben.carsey@intel.com>
> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg
> from edk2/master
> 
> On 04/03/19 04:17, Ni, Ray wrote:
> >
> >
> >> -----Original Message-----
> >> From: edk2-devel <edk2-devel-bounces@lists.01.org>
> On Behalf Of Laszlo
> >> Ersek
> >> Sent: Tuesday, April 2, 2019 4:49 PM
> >> To: Bi, Dandan <dandan.bi@intel.com>; edk2-
> devel@lists.01.org
> >> Cc: Cetola, Stephano <stephano.cetola@intel.com>;
> Kinney, Michael D
> >> <michael.d.kinney@intel.com>; Gao, Liming
> <liming.gao@intel.com>; Carsey,
> >> Jaben <jaben.carsey@intel.com>
> >> Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg
> from edk2/master
> >>
> >> On 04/02/19 07:38, Bi, Dandan wrote:
> >>> Hi All,
> >>>
> >>> ShellBinPkg is the remaining binary package in Edk2
> repo.  We plan to
> >> delete ShellBinPkg from edk2/master, and keep source
> ShellPkg only in edk2
> >> repo.
> >>> Before the deletion, I will update the existing
> consumers in Edk2 and
> >> Edk2Platforms to use ShellPkg directly.
> >>>
> >>> If you have any concern please raise here before
> mid-April . If there is no
> >> concern, I will create patches for this task after
> mid-April.
> >>>
> >>> Bugzilla for this task:
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=1675
> >>
> >> (adding a few CC's)
> >>
> >> I think we should not remove ShellBinPkg without a
> replacement
> >> *somehwere*.
> >>
> >> A shell binary that is built from a validated edk2
> tree, with a set of library
> >> resolutions and PCD settings that are known to keep
> platform dependencies
> >> *out* of the shell binary, is extremely useful.
> >
> > I understand the concern.
> > Maybe a "Shell.dsc.inc" provided by ShellPkg which
> lists all library resolutions
> > , PCD settings and build options can be included by
> platform DSC to resolve such
> > dependency issue.
> >
> >>
> >> IIRC, Andrew suggested earlier that we should treat
> the shell even as an "OS",
> >> with better compatibility standards than we
> currently maintain.
> >>
> >> I think we should only remove ShellBinPkg if we
> permanently offer a
> >> separate download location instead, and we rebuild
> the shell binary from
> >> "ShellPkg/ShellPkg.dsc" at every stable tag.
> >
> > I do not quite understand. All other modules in edk2
> repo are source-included by
> > OvmfPkg and daily commits directly generates new
> binaries for OvmfPkg.
> > I do not think we should have a different "binary-
> generation" model for
> > shell.
> 
> The standalone shell binary would not be offered for
> OVMF, but for all
> possible UEFI platforms (physical and virtual alike).
> 
> People frequently turn to the UEFI shell for debugging
> UEFI issues on
> their physical machines. Such users are generally not
> interested in
> building the shell from source, just booting it as
> easily as possible.
> 
> Thanks,
> Laszlo
> 
> 
> >> In that case, removing ShellBinPkg would indeed
> improve the edk2 tree, in
> >> my opinion.
> >>
> >> Thanks,
> >> Laszlo
> >> _______________________________________________
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Laszlo Ersek <lersek@redhat.com>
Details
Message ID
<565232dc-a0ff-7b1b-3a7c-9c6db0b26969@redhat.com>
In-Reply-To
<E92EE9817A31E24EB0585FDF735412F5B9C774C3@ORSMSX112.amr.corp.intel.com> (view parent)
Sender timestamp
1554307624
DKIM signature
missing
Download raw message
On 04/03/19 17:49, Kinney, Michael D wrote:
> Laszlo,
> 
> I think it makes sense to post validated shell binaries
> with the edk2-stable tag releases.  GitHub does support
> this when a release tag is made.
> 
> However, we would need to make it simple for a platform
> to use a binary from that location.  We may need some
> enhancements to pull in binary artifacts from different
> locations to support a platform build that uses one or
> more pre-built binaries.

Can PREBUILD scripts (written by platform owners) download the required
binaries?

Thanks,
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Reply to thread Export thread (mbox)