[RFC] Proposal to add edk2-apps repository

[RFC] Proposal to add edk2-apps repository

[Kinney, Michael D]

Hello,

I would like to propose the creation of a new
repository called edk2-apps.  This repository
would initially be used to host the following
packages from the edk2 repository:

* AppPkg
* StdLib
* StdLibPrivateInternalFiles

These 3 packages provide support for the libc along
with applications that depend on libc.  None of the
other packages in the edk2 repository use these
packages, so these 3 package can be safely moved
without any impacts to platform firmware builds.
Build configurations that do use libc features can
clone the edk2-apps repository and add it to
PACKAGES_PATH.

The history of these 3 packages would be preserved
when importing the content into edk2-apps.  After
The import is verified, these 3 packages would be
deleted from the edk2 repository.

This proposal helps reduce the size of the edk2
repository and focuses edk2 repository on packages
used to provide UEFI/PI conformant firmware.

If there are no concerns with this proposal, I will
enter a Tianocore BZs for the two steps.

Best regards,

Mike

Re: [RFC] Proposal to add edk2-apps repository

[Leif Lindholm]

On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael D wrote:
> Hello,
> 
> I would like to propose the creation of a new
> repository called edk2-apps.  This repository
> would initially be used to host the following
> packages from the edk2 repository:
> 
> * AppPkg
> * StdLib
> * StdLibPrivateInternalFiles

Let me start by saying I 100% back moving these out of the main edk2
repository.

> These 3 packages provide support for the libc along
> with applications that depend on libc.  None of the
> other packages in the edk2 repository use these
> packages, so these 3 package can be safely moved
> without any impacts to platform firmware builds.
> Build configurations that do use libc features can
> clone the edk2-apps repository and add it to
> PACKAGES_PATH.

I must confess to never having properly understood the scope of AppPkg
to begin with.

AppPkg/Applications/Hello does not appear to have any further (real)
dependency on libc than MdeModulePkg/Application/HelloWorld/, and .

And certainly MdeModulePkg/Applications contain plenty of
... applications.

So, if the purpose is simply to provide some examples of application
written to libc rather than UEFI - should this be edk2-libc instead?

Best Regards,

Leif

> The history of these 3 packages would be preserved
> when importing the content into edk2-apps.  After
> The import is verified, these 3 packages would be
> deleted from the edk2 repository.
> 
> This proposal helps reduce the size of the edk2
> repository and focuses edk2 repository on packages
> used to provide UEFI/PI conformant firmware.
> 
> If there are no concerns with this proposal, I will
> enter a Tianocore BZs for the two steps.
> 
> Best regards,
> 
> Mike
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] Proposal to add edk2-apps repository

[Kinney, Michael D]

Leif,

I did consider the edk2-libc name.  The port of Python 2.7 
is in the AppPkg as well and it uses libc.

So the content of this new package is a combination of libc
And apps that use libc.

I am definitely open to alternate names.  2 options so far:

* edk2-apps
* edk2-libc

Thanks,

Mike

> -----Original Message-----
> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
> Sent: Thursday, November 29, 2018 2:41 PM
> To: Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps
> repository
> 
> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael
> D wrote:
> > Hello,
> >
> > I would like to propose the creation of a new
> > repository called edk2-apps.  This repository
> > would initially be used to host the following
> > packages from the edk2 repository:
> >
> > * AppPkg
> > * StdLib
> > * StdLibPrivateInternalFiles
> 
> Let me start by saying I 100% back moving these out of the
> main edk2
> repository.
> 
> > These 3 packages provide support for the libc along
> > with applications that depend on libc.  None of the
> > other packages in the edk2 repository use these
> > packages, so these 3 package can be safely moved
> > without any impacts to platform firmware builds.
> > Build configurations that do use libc features can
> > clone the edk2-apps repository and add it to
> > PACKAGES_PATH.
> 
> I must confess to never having properly understood the
> scope of AppPkg
> to begin with.
> 
> AppPkg/Applications/Hello does not appear to have any
> further (real)
> dependency on libc than
> MdeModulePkg/Application/HelloWorld/, and .
> 
> And certainly MdeModulePkg/Applications contain plenty of
> ... applications.
> 
> So, if the purpose is simply to provide some examples of
> application
> written to libc rather than UEFI - should this be edk2-
> libc instead?
> 
> Best Regards,
> 
> Leif
> 
> > The history of these 3 packages would be preserved
> > when importing the content into edk2-apps.  After
> > The import is verified, these 3 packages would be
> > deleted from the edk2 repository.
> >
> > This proposal helps reduce the size of the edk2
> > repository and focuses edk2 repository on packages
> > used to provide UEFI/PI conformant firmware.
> >
> > If there are no concerns with this proposal, I will
> > enter a Tianocore BZs for the two steps.
> >
> > Best regards,
> >
> > Mike
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] Proposal to add edk2-apps repository

[krishnaLee]

Kinney,
I always think there may be two kinds of apps:
1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,...they usually execute under uefi_shell),I would call them "uefi_shell_application";
2,some apps have no dependency on uefi_shell(such as apps in MdeModulePkg/Application),I would call them "standard_uefi_application".

The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used by uefi_shell_application,I think they can all move to ShellPkg,no need to create new package ?


Thanks,
krishna.

At 2018-11-30 08:46:58, "Kinney, Michael D" <michael.d.kinney@intel.com> wrote:
>Leif,
>
>I did consider the edk2-libc name.  The port of Python 2.7 
>is in the AppPkg as well and it uses libc.
>
>So the content of this new package is a combination of libc
>And apps that use libc.
>
>I am definitely open to alternate names.  2 options so far:
>
>* edk2-apps
>* edk2-libc
>
>Thanks,
>
>Mike
>
>> -----Original Message-----
>> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
>> Sent: Thursday, November 29, 2018 2:41 PM
>> To: Kinney, Michael D <michael.d.kinney@intel.com>
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps
>> repository
>> 
>> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael
>> D wrote:
>> > Hello,
>> >
>> > I would like to propose the creation of a new
>> > repository called edk2-apps.  This repository
>> > would initially be used to host the following
>> > packages from the edk2 repository:
>> >
>> > * AppPkg
>> > * StdLib
>> > * StdLibPrivateInternalFiles
>> 
>> Let me start by saying I 100% back moving these out of the
>> main edk2
>> repository.
>> 
>> > These 3 packages provide support for the libc along
>> > with applications that depend on libc.  None of the
>> > other packages in the edk2 repository use these
>> > packages, so these 3 package can be safely moved
>> > without any impacts to platform firmware builds.
>> > Build configurations that do use libc features can
>> > clone the edk2-apps repository and add it to
>> > PACKAGES_PATH.
>> 
>> I must confess to never having properly understood the
>> scope of AppPkg
>> to begin with.
>> 
>> AppPkg/Applications/Hello does not appear to have any
>> further (real)
>> dependency on libc than
>> MdeModulePkg/Application/HelloWorld/, and .
>> 
>> And certainly MdeModulePkg/Applications contain plenty of
>> ... applications.
>> 
>> So, if the purpose is simply to provide some examples of
>> application
>> written to libc rather than UEFI - should this be edk2-
>> libc instead?
>> 
>> Best Regards,
>> 
>> Leif
>> 
>> > The history of these 3 packages would be preserved
>> > when importing the content into edk2-apps.  After
>> > The import is verified, these 3 packages would be
>> > deleted from the edk2 repository.
>> >
>> > This proposal helps reduce the size of the edk2
>> > repository and focuses edk2 repository on packages
>> > used to provide UEFI/PI conformant firmware.
>> >
>> > If there are no concerns with this proposal, I will
>> > enter a Tianocore BZs for the two steps.
>> >
>> > Best regards,
>> >
>> > Mike
>> > _______________________________________________
>> > 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

Re: [RFC] Proposal to add edk2-apps repository

[Ni, Ruiyu]

Krishna,
The reason there are applications inside MdeModulePkg/Application is that the shell protocol was in ShellPkg when the app was developed and MdeModulePkg cannot depend on ShellPkg (rule).
Now since shell protocol is moved to MdePkg, any apps can depend on shell protocol. (In fact they wanted to but just wasn't allowed due to reason above.)

I even prefer to move the ShellPkg to the edk2-app repo Mike proposed. Instead of enlarge the ShellPkg:)

I don't prefer edk2-libc unless we have a strategy/plan to make ordinary C developer easy by promoting the std-c pkg.
The other reason I prefer edk2-app is then ShellPkg might be moved to that new repo.


> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> krishnaLee
> Sent: Friday, November 30, 2018 9:45 AM
> To: edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
> 
> Kinney,
> I always think there may be two kinds of apps:
> 1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,...they
> usually execute under uefi_shell),I would call them "uefi_shell_application";
> 2,some apps have no dependency on uefi_shell(such as apps in
> MdeModulePkg/Application),I would call them "standard_uefi_application".
> 
> The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used by
> uefi_shell_application,I think they can all move to ShellPkg,no need to create
> new package ?
> 
> 
> Thanks,
> krishna.
> 
> At 2018-11-30 08:46:58, "Kinney, Michael D" <michael.d.kinney@intel.com>
> wrote:
> >Leif,
> >
> >I did consider the edk2-libc name.  The port of Python 2.7 is in the
> >AppPkg as well and it uses libc.
> >
> >So the content of this new package is a combination of libc And apps
> >that use libc.
> >
> >I am definitely open to alternate names.  2 options so far:
> >
> >* edk2-apps
> >* edk2-libc
> >
> >Thanks,
> >
> >Mike
> >
> >> -----Original Message-----
> >> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
> >> Sent: Thursday, November 29, 2018 2:41 PM
> >> To: Kinney, Michael D <michael.d.kinney@intel.com>
> >> Cc: edk2-devel@lists.01.org
> >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
> >>
> >> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael D wrote:
> >> > Hello,
> >> >
> >> > I would like to propose the creation of a new repository called
> >> > edk2-apps.  This repository would initially be used to host the
> >> > following packages from the edk2 repository:
> >> >
> >> > * AppPkg
> >> > * StdLib
> >> > * StdLibPrivateInternalFiles
> >>
> >> Let me start by saying I 100% back moving these out of the main edk2
> >> repository.
> >>
> >> > These 3 packages provide support for the libc along with
> >> > applications that depend on libc.  None of the other packages in
> >> > the edk2 repository use these packages, so these 3 package can be
> >> > safely moved without any impacts to platform firmware builds.
> >> > Build configurations that do use libc features can clone the
> >> > edk2-apps repository and add it to PACKAGES_PATH.
> >>
> >> I must confess to never having properly understood the scope of
> >> AppPkg to begin with.
> >>
> >> AppPkg/Applications/Hello does not appear to have any further (real)
> >> dependency on libc than MdeModulePkg/Application/HelloWorld/, and .
> >>
> >> And certainly MdeModulePkg/Applications contain plenty of ...
> >> applications.
> >>
> >> So, if the purpose is simply to provide some examples of application
> >> written to libc rather than UEFI - should this be edk2- libc instead?
> >>
> >> Best Regards,
> >>
> >> Leif
> >>
> >> > The history of these 3 packages would be preserved when importing
> >> > the content into edk2-apps.  After The import is verified, these 3
> >> > packages would be deleted from the edk2 repository.
> >> >
> >> > This proposal helps reduce the size of the edk2 repository and
> >> > focuses edk2 repository on packages used to provide UEFI/PI
> >> > conformant firmware.
> >> >
> >> > If there are no concerns with this proposal, I will enter a
> >> > Tianocore BZs for the two steps.
> >> >
> >> > Best regards,
> >> >
> >> > Mike
> >> > _______________________________________________
> >> > 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
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] Proposal to add edk2-apps repository

[Carsey, Jaben]

I do not think that expanding shellPkg would work since there is no requirement that any of these apps depend on it.  As was stated, MicroPythonPkg does not.

I also do not think that moving ShellPkg makes lots of sense since it is used by many platforms.

-Jaben

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ni,
> Ruiyu
> Sent: Thursday, November 29, 2018 7:40 PM
> To: krishnaLee <sssky307@163.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
> Importance: High
> 
> Krishna,
> The reason there are applications inside MdeModulePkg/Application is that
> the shell protocol was in ShellPkg when the app was developed and
> MdeModulePkg cannot depend on ShellPkg (rule).
> Now since shell protocol is moved to MdePkg, any apps can depend on shell
> protocol. (In fact they wanted to but just wasn't allowed due to reason
> above.)
> 
> I even prefer to move the ShellPkg to the edk2-app repo Mike proposed.
> Instead of enlarge the ShellPkg:)
> 
> I don't prefer edk2-libc unless we have a strategy/plan to make ordinary C
> developer easy by promoting the std-c pkg.
> The other reason I prefer edk2-app is then ShellPkg might be moved to that
> new repo.
> 
> 
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> > krishnaLee
> > Sent: Friday, November 30, 2018 9:45 AM
> > To: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
> >
> > Kinney,
> > I always think there may be two kinds of apps:
> > 1,some apps have dependency on uefi_shell(shell-
> lib,efi_shell_protocol,...they
> > usually execute under uefi_shell),I would call them
> "uefi_shell_application";
> > 2,some apps have no dependency on uefi_shell(such as apps in
> > MdeModulePkg/Application),I would call them
> "standard_uefi_application".
> >
> > The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually
> used by
> > uefi_shell_application,I think they can all move to ShellPkg,no need to
> create
> > new package ?
> >
> >
> > Thanks,
> > krishna.
> >
> > At 2018-11-30 08:46:58, "Kinney, Michael D" <michael.d.kinney@intel.com>
> > wrote:
> > >Leif,
> > >
> > >I did consider the edk2-libc name.  The port of Python 2.7 is in the
> > >AppPkg as well and it uses libc.
> > >
> > >So the content of this new package is a combination of libc And apps
> > >that use libc.
> > >
> > >I am definitely open to alternate names.  2 options so far:
> > >
> > >* edk2-apps
> > >* edk2-libc
> > >
> > >Thanks,
> > >
> > >Mike
> > >
> > >> -----Original Message-----
> > >> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
> > >> Sent: Thursday, November 29, 2018 2:41 PM
> > >> To: Kinney, Michael D <michael.d.kinney@intel.com>
> > >> Cc: edk2-devel@lists.01.org
> > >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
> > >>
> > >> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael D wrote:
> > >> > Hello,
> > >> >
> > >> > I would like to propose the creation of a new repository called
> > >> > edk2-apps.  This repository would initially be used to host the
> > >> > following packages from the edk2 repository:
> > >> >
> > >> > * AppPkg
> > >> > * StdLib
> > >> > * StdLibPrivateInternalFiles
> > >>
> > >> Let me start by saying I 100% back moving these out of the main edk2
> > >> repository.
> > >>
> > >> > These 3 packages provide support for the libc along with
> > >> > applications that depend on libc.  None of the other packages in
> > >> > the edk2 repository use these packages, so these 3 package can be
> > >> > safely moved without any impacts to platform firmware builds.
> > >> > Build configurations that do use libc features can clone the
> > >> > edk2-apps repository and add it to PACKAGES_PATH.
> > >>
> > >> I must confess to never having properly understood the scope of
> > >> AppPkg to begin with.
> > >>
> > >> AppPkg/Applications/Hello does not appear to have any further (real)
> > >> dependency on libc than MdeModulePkg/Application/HelloWorld/, and
> .
> > >>
> > >> And certainly MdeModulePkg/Applications contain plenty of ...
> > >> applications.
> > >>
> > >> So, if the purpose is simply to provide some examples of application
> > >> written to libc rather than UEFI - should this be edk2- libc instead?
> > >>
> > >> Best Regards,
> > >>
> > >> Leif
> > >>
> > >> > The history of these 3 packages would be preserved when importing
> > >> > the content into edk2-apps.  After The import is verified, these 3
> > >> > packages would be deleted from the edk2 repository.
> > >> >
> > >> > This proposal helps reduce the size of the edk2 repository and
> > >> > focuses edk2 repository on packages used to provide UEFI/PI
> > >> > conformant firmware.
> > >> >
> > >> > If there are no concerns with this proposal, I will enter a
> > >> > Tianocore BZs for the two steps.
> > >> >
> > >> > Best regards,
> > >> >
> > >> > Mike
> > >> > _______________________________________________
> > >> > 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
> > _______________________________________________
> > 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

Re: [RFC] Proposal to add edk2-apps repository

[Kinney, Michael D]

One of the goals with this proposal is to minimize
the amount of source code that needs to be setup in
a WORKSPACE to build firmware for a given platform.
If a platform does not require any applications that
require the libc, then it would be better if the libc
related packages and applications that use libc do not
have to be present in WORKSPACE.

Likewise, there are platforms that do not require the
UEFI Shell or any other UEFI Applications in order to
build the platform firmware image.

Perhaps we need one repo for libc related content and
another repo for UEFI Application related content.

Best regards,

Mike


> -----Original Message-----
> From: Carsey, Jaben
> Sent: Friday, November 30, 2018 7:50 AM
> To: Ni, Ruiyu <ruiyu.ni@intel.com>; krishnaLee
> <sssky307@163.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [RFC] Proposal to add edk2-apps
> repository
> 
> I do not think that expanding shellPkg would work since
> there is no requirement that any of these apps depend
> on it.  As was stated, MicroPythonPkg does not.
> 
> I also do not think that moving ShellPkg makes lots of
> sense since it is used by many platforms.
> 
> -Jaben
> 
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-
> bounces@lists.01.org] On Behalf Of Ni,
> > Ruiyu
> > Sent: Thursday, November 29, 2018 7:40 PM
> > To: krishnaLee <sssky307@163.com>; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps
> repository
> > Importance: High
> >
> > Krishna,
> > The reason there are applications inside
> MdeModulePkg/Application is that
> > the shell protocol was in ShellPkg when the app was
> developed and
> > MdeModulePkg cannot depend on ShellPkg (rule).
> > Now since shell protocol is moved to MdePkg, any apps
> can depend on shell
> > protocol. (In fact they wanted to but just wasn't
> allowed due to reason
> > above.)
> >
> > I even prefer to move the ShellPkg to the edk2-app
> repo Mike proposed.
> > Instead of enlarge the ShellPkg:)
> >
> > I don't prefer edk2-libc unless we have a
> strategy/plan to make ordinary C
> > developer easy by promoting the std-c pkg.
> > The other reason I prefer edk2-app is then ShellPkg
> might be moved to that
> > new repo.
> >
> >
> > > -----Original Message-----
> > > From: edk2-devel [mailto:edk2-devel-
> bounces@lists.01.org] On Behalf Of
> > > krishnaLee
> > > Sent: Friday, November 30, 2018 9:45 AM
> > > To: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] [RFC] Proposal to add edk2-apps
> repository
> > >
> > > Kinney,
> > > I always think there may be two kinds of apps:
> > > 1,some apps have dependency on uefi_shell(shell-
> > lib,efi_shell_protocol,...they
> > > usually execute under uefi_shell),I would call them
> > "uefi_shell_application";
> > > 2,some apps have no dependency on uefi_shell(such
> as apps in
> > > MdeModulePkg/Application),I would call them
> > "standard_uefi_application".
> > >
> > > The "AppPkg / StdLib / StdLibPrivateInternalFiles"
> packages are usually
> > used by
> > > uefi_shell_application,I think they can all move to
> ShellPkg,no need to
> > create
> > > new package ?
> > >
> > >
> > > Thanks,
> > > krishna.
> > >
> > > At 2018-11-30 08:46:58, "Kinney, Michael D"
> <michael.d.kinney@intel.com>
> > > wrote:
> > > >Leif,
> > > >
> > > >I did consider the edk2-libc name.  The port of
> Python 2.7 is in the
> > > >AppPkg as well and it uses libc.
> > > >
> > > >So the content of this new package is a
> combination of libc And apps
> > > >that use libc.
> > > >
> > > >I am definitely open to alternate names.  2
> options so far:
> > > >
> > > >* edk2-apps
> > > >* edk2-libc
> > > >
> > > >Thanks,
> > > >
> > > >Mike
> > > >
> > > >> -----Original Message-----
> > > >> From: Leif Lindholm
> [mailto:leif.lindholm@linaro.org]
> > > >> Sent: Thursday, November 29, 2018 2:41 PM
> > > >> To: Kinney, Michael D
> <michael.d.kinney@intel.com>
> > > >> Cc: edk2-devel@lists.01.org
> > > >> Subject: Re: [edk2] [RFC] Proposal to add edk2-
> apps repository
> > > >>
> > > >> On Thu, Nov 29, 2018 at 05:58:08PM +0000,
> Kinney, Michael D wrote:
> > > >> > Hello,
> > > >> >
> > > >> > I would like to propose the creation of a new
> repository called
> > > >> > edk2-apps.  This repository would initially be
> used to host the
> > > >> > following packages from the edk2 repository:
> > > >> >
> > > >> > * AppPkg
> > > >> > * StdLib
> > > >> > * StdLibPrivateInternalFiles
> > > >>
> > > >> Let me start by saying I 100% back moving these
> out of the main edk2
> > > >> repository.
> > > >>
> > > >> > These 3 packages provide support for the libc
> along with
> > > >> > applications that depend on libc.  None of the
> other packages in
> > > >> > the edk2 repository use these packages, so
> these 3 package can be
> > > >> > safely moved without any impacts to platform
> firmware builds.
> > > >> > Build configurations that do use libc features
> can clone the
> > > >> > edk2-apps repository and add it to
> PACKAGES_PATH.
> > > >>
> > > >> I must confess to never having properly
> understood the scope of
> > > >> AppPkg to begin with.
> > > >>
> > > >> AppPkg/Applications/Hello does not appear to
> have any further (real)
> > > >> dependency on libc than
> MdeModulePkg/Application/HelloWorld/, and
> > .
> > > >>
> > > >> And certainly MdeModulePkg/Applications contain
> plenty of ...
> > > >> applications.
> > > >>
> > > >> So, if the purpose is simply to provide some
> examples of application
> > > >> written to libc rather than UEFI - should this
> be edk2- libc instead?
> > > >>
> > > >> Best Regards,
> > > >>
> > > >> Leif
> > > >>
> > > >> > The history of these 3 packages would be
> preserved when importing
> > > >> > the content into edk2-apps.  After The import
> is verified, these 3
> > > >> > packages would be deleted from the edk2
> repository.
> > > >> >
> > > >> > This proposal helps reduce the size of the
> edk2 repository and
> > > >> > focuses edk2 repository on packages used to
> provide UEFI/PI
> > > >> > conformant firmware.
> > > >> >
> > > >> > If there are no concerns with this proposal, I
> will enter a
> > > >> > Tianocore BZs for the two steps.
> > > >> >
> > > >> > Best regards,
> > > >> >
> > > >> > Mike
> > > >> >
> _______________________________________________
> > > >> > 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
> > > _______________________________________________
> > > 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

Re: [RFC] Proposal to add edk2-apps repository

[krishnaLee]

Ruiyu,

At 2018-11-30 11:40:06, "Ni, Ruiyu" <ruiyu.ni@intel.com> wrote:
>I don't prefer edk2-libc unless we have a strategy/plan to make ordinary C developer easy by promoting the std-c pkg.
>The other reason I prefer edk2-app is then ShellPkg might be moved to that new repo.

I used to think ShellPkg can also develop apps has no dependency on it or libc,it would be a big app-container,but it seems its name will be mis-understanding...
I think your idea has the same function,and it's much better.


thanks,
krishna.








>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>> krishnaLee
>> Sent: Friday, November 30, 2018 9:45 AM
>> To: edk2-devel@lists.01.org
>> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
>> 
>> Kinney,
>> I always think there may be two kinds of apps:
>> 1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,...they
>> usually execute under uefi_shell),I would call them "uefi_shell_application";
>> 2,some apps have no dependency on uefi_shell(such as apps in
>> MdeModulePkg/Application),I would call them "standard_uefi_application".
>> 
>> The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used by
>> uefi_shell_application,I think they can all move to ShellPkg,no need to create
>> new package ?
>> 
>> 
>> Thanks,
>> krishna.
>> 
>> At 2018-11-30 08:46:58, "Kinney, Michael D" <michael.d.kinney@intel.com>
>> wrote:
>> >Leif,
>> >
>> >I did consider the edk2-libc name.  The port of Python 2.7 is in the
>> >AppPkg as well and it uses libc.
>> >
>> >So the content of this new package is a combination of libc And apps
>> >that use libc.
>> >
>> >I am definitely open to alternate names.  2 options so far:
>> >
>> >* edk2-apps
>> >* edk2-libc
>> >
>> >Thanks,
>> >
>> >Mike
>> >
>> >> -----Original Message-----
>> >> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
>> >> Sent: Thursday, November 29, 2018 2:41 PM
>> >> To: Kinney, Michael D <michael.d.kinney@intel.com>
>> >> Cc: edk2-devel@lists.01.org
>> >> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps repository
>> >>
>> >> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael D wrote:
>> >> > Hello,
>> >> >
>> >> > I would like to propose the creation of a new repository called
>> >> > edk2-apps.  This repository would initially be used to host the
>> >> > following packages from the edk2 repository:
>> >> >
>> >> > * AppPkg
>> >> > * StdLib
>> >> > * StdLibPrivateInternalFiles
>> >>
>> >> Let me start by saying I 100% back moving these out of the main edk2
>> >> repository.
>> >>
>> >> > These 3 packages provide support for the libc along with
>> >> > applications that depend on libc.  None of the other packages in
>> >> > the edk2 repository use these packages, so these 3 package can be
>> >> > safely moved without any impacts to platform firmware builds.
>> >> > Build configurations that do use libc features can clone the
>> >> > edk2-apps repository and add it to PACKAGES_PATH.
>> >>
>> >> I must confess to never having properly understood the scope of
>> >> AppPkg to begin with.
>> >>
>> >> AppPkg/Applications/Hello does not appear to have any further (real)
>> >> dependency on libc than MdeModulePkg/Application/HelloWorld/, and .
>> >>
>> >> And certainly MdeModulePkg/Applications contain plenty of ...
>> >> applications.
>> >>
>> >> So, if the purpose is simply to provide some examples of application
>> >> written to libc rather than UEFI - should this be edk2- libc instead?
>> >>
>> >> Best Regards,
>> >>
>> >> Leif
>> >>
>> >> > The history of these 3 packages would be preserved when importing
>> >> > the content into edk2-apps.  After The import is verified, these 3
>> >> > packages would be deleted from the edk2 repository.
>> >> >
>> >> > This proposal helps reduce the size of the edk2 repository and
>> >> > focuses edk2 repository on packages used to provide UEFI/PI
>> >> > conformant firmware.
>> >> >
>> >> > If there are no concerns with this proposal, I will enter a
>> >> > Tianocore BZs for the two steps.
>> >> >
>> >> > Best regards,
>> >> >
>> >> > Mike
>> >> > _______________________________________________
>> >> > 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
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
\x16&#65533;&

Re: [RFC] Proposal to add edk2-apps repository

[Andrew Fish]

Mike,

As Krishna points out there are flavors of Apps. Do we want to have different packages for different flavor of apps, or different dirs in a more generic App package? Maybe we should define classes of UEFI Applications in the README.md and give them a place to live. 

I don't want to get too pedantic so we can have a 1st level of if you depend on X you go here. Maybe something if you depend on the clib you go in the Clib dir, if you depend on Shell you go in Shell. With a priority to the list so clib always means clib dir. etc.?

Thanks,

Andrew Fish

> On Nov 29, 2018, at 5:44 PM, krishnaLee <sssky307@163.com> wrote:
> 
> Kinney,
> I always think there may be two kinds of apps:
> 1,some apps have dependency on uefi_shell(shell-lib,efi_shell_protocol,...they usually execute under uefi_shell),I would call them "uefi_shell_application";
> 2,some apps have no dependency on uefi_shell(such as apps in MdeModulePkg/Application),I would call them "standard_uefi_application".
> 
> The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used by uefi_shell_application,I think they can all move to ShellPkg,no need to create new package ?
> 
> 
> Thanks,
> krishna.
> 
> At 2018-11-30 08:46:58, "Kinney, Michael D" <michael.d.kinney@intel.com> wrote:
>> Leif,
>> 
>> I did consider the edk2-libc name.  The port of Python 2.7 
>> is in the AppPkg as well and it uses libc.
>> 
>> So the content of this new package is a combination of libc
>> And apps that use libc.
>> 
>> I am definitely open to alternate names.  2 options so far:
>> 
>> * edk2-apps
>> * edk2-libc
>> 
>> Thanks,
>> 
>> Mike
>> 
>>> -----Original Message-----
>>> From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
>>> Sent: Thursday, November 29, 2018 2:41 PM
>>> To: Kinney, Michael D <michael.d.kinney@intel.com>
>>> Cc: edk2-devel@lists.01.org
>>> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps
>>> repository
>>> 
>>> On Thu, Nov 29, 2018 at 05:58:08PM +0000, Kinney, Michael
>>> D wrote:
>>>> Hello,
>>>> 
>>>> I would like to propose the creation of a new
>>>> repository called edk2-apps.  This repository
>>>> would initially be used to host the following
>>>> packages from the edk2 repository:
>>>> 
>>>> * AppPkg
>>>> * StdLib
>>>> * StdLibPrivateInternalFiles
>>> 
>>> Let me start by saying I 100% back moving these out of the
>>> main edk2
>>> repository.
>>> 
>>>> These 3 packages provide support for the libc along
>>>> with applications that depend on libc.  None of the
>>>> other packages in the edk2 repository use these
>>>> packages, so these 3 package can be safely moved
>>>> without any impacts to platform firmware builds.
>>>> Build configurations that do use libc features can
>>>> clone the edk2-apps repository and add it to
>>>> PACKAGES_PATH.
>>> 
>>> I must confess to never having properly understood the
>>> scope of AppPkg
>>> to begin with.
>>> 
>>> AppPkg/Applications/Hello does not appear to have any
>>> further (real)
>>> dependency on libc than
>>> MdeModulePkg/Application/HelloWorld/, and .
>>> 
>>> And certainly MdeModulePkg/Applications contain plenty of
>>> ... applications.
>>> 
>>> So, if the purpose is simply to provide some examples of
>>> application
>>> written to libc rather than UEFI - should this be edk2-
>>> libc instead?
>>> 
>>> Best Regards,
>>> 
>>> Leif
>>> 
>>>> The history of these 3 packages would be preserved
>>>> when importing the content into edk2-apps.  After
>>>> The import is verified, these 3 packages would be
>>>> deleted from the edk2 repository.
>>>> 
>>>> This proposal helps reduce the size of the edk2
>>>> repository and focuses edk2 repository on packages
>>>> used to provide UEFI/PI conformant firmware.
>>>> 
>>>> If there are no concerns with this proposal, I will
>>>> enter a Tianocore BZs for the two steps.
>>>> 
>>>> Best regards,
>>>> 
>>>> Mike
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] Proposal to add edk2-apps repository

[Laszlo Ersek]

On 11/30/18 07:03, Andrew Fish wrote:
> Mike,
>
> As Krishna points out there are flavors of Apps. Do we want to have
> different packages for different flavor of apps, or different dirs in
> a more generic App package? Maybe we should define classes of UEFI
> Applications in the README.md and give them a place to live.

In my opinion, this is absolutely the first step that should be done.

Personally, I've just learned, from this thread, that there are *three*
(not two) UEFI application entry point types that edk2 supports.

* I've always known about main() -- libc app --, and ShellAppMain() --
  shell app. I've always known these because I read about them in
  "AppPkg/ReadMe.txt" and "StdLib/ReadMe.txt" years ago. In particular,
  compare the description of "Hello" and "Main".

* And now MdeModulePkg/Application has been mentioned, in this thread,
  where I see UefiMain() as the entry point.

I don't recall reading about UefiMain() or UefiApplicationEntryPoint on
this list. On the other hand, I remember several discussions where
people asked if they could write an application and invoke it from
SysPrep#### or similar, and the answer has always been, "oh sorry you
can't do that, because the lowest level you can go is ShellAppMain(),
and that won't work from SysPrep####".

Thanks
Laszlo

Re: [RFC] Proposal to add edk2-apps repository

[Leif Lindholm]

On Mon, Dec 03, 2018 at 03:11:33PM +0100, Laszlo Ersek wrote:
> On 11/30/18 07:03, Andrew Fish wrote:
> > Mike,
> >
> > As Krishna points out there are flavors of Apps. Do we want to have
> > different packages for different flavor of apps, or different dirs in
> > a more generic App package? Maybe we should define classes of UEFI
> > Applications in the README.md and give them a place to live.
> 
> In my opinion, this is absolutely the first step that should be done.

Yes please.

> Personally, I've just learned, from this thread, that there are *three*
> (not two) UEFI application entry point types that edk2 supports.
> 
> * I've always known about main() -- libc app --, and ShellAppMain() --
>   shell app. I've always known these because I read about them in
>   "AppPkg/ReadMe.txt" and "StdLib/ReadMe.txt" years ago. In particular,
>   compare the description of "Hello" and "Main".
> 
> * And now MdeModulePkg/Application has been mentioned, in this thread,
>   where I see UefiMain() as the entry point.

Well, these are defined by the application .inf though, so "UefiMain"
is just a common name picked. MdeModulePkg/Application also has
applications with entry points called 'BootManagerMenuEntry',
'SmiHandlerProfileInfoEntrypoint' and 'InitializeUserInterface'. (The
latter being UiApp.)

> I don't recall reading about UefiMain() or UefiApplicationEntryPoint on
> this list. On the other hand, I remember several discussions where
> people asked if they could write an application and invoke it from
> SysPrep#### or similar, and the answer has always been, "oh sorry you
> can't do that, because the lowest level you can go is ShellAppMain(),
> and that won't work from SysPrep####".

Huh? Who claimed that? Where?

(I suspect the meaning of "Application" has taken on some
overly-specific meaning for someone if they have claimed such - going
back to how having a proper definition is clearly quite important.)

Of course they can. Any EDK2 image itself contains a bunch of .efi
executables - and there is nothing preventing you from invoking those
from the shell.

And don't forget most platforms ship without a built-in Shell, so
there would be no way of running ... anything ... if that was true.

Also, it's pretty much the whole point of gnu-efi (combined with doing
it directly in a normal POSIX environment).

/
    Leif

Re: [RFC] Proposal to add edk2-apps repository

[Laszlo Ersek]

On 12/03/18 16:07, Leif Lindholm wrote:
> On Mon, Dec 03, 2018 at 03:11:33PM +0100, Laszlo Ersek wrote:
>> On 11/30/18 07:03, Andrew Fish wrote:
>>> Mike,
>>>
>>> As Krishna points out there are flavors of Apps. Do we want to have
>>> different packages for different flavor of apps, or different dirs in
>>> a more generic App package? Maybe we should define classes of UEFI
>>> Applications in the README.md and give them a place to live.
>>
>> In my opinion, this is absolutely the first step that should be done.
> 
> Yes please.
> 
>> Personally, I've just learned, from this thread, that there are *three*
>> (not two) UEFI application entry point types that edk2 supports.
>>
>> * I've always known about main() -- libc app --, and ShellAppMain() --
>>   shell app. I've always known these because I read about them in
>>   "AppPkg/ReadMe.txt" and "StdLib/ReadMe.txt" years ago. In particular,
>>   compare the description of "Hello" and "Main".
>>
>> * And now MdeModulePkg/Application has been mentioned, in this thread,
>>   where I see UefiMain() as the entry point.
> 
> Well, these are defined by the application .inf though, so "UefiMain"
> is just a common name picked. MdeModulePkg/Application also has
> applications with entry points called 'BootManagerMenuEntry',
> 'SmiHandlerProfileInfoEntrypoint' and 'InitializeUserInterface'. (The
> latter being UiApp.)

Right, I guess I should have referred to the "UefiApplicationEntryPoint"
lib class instead. (I did so below.)

> 
>> I don't recall reading about UefiMain() or UefiApplicationEntryPoint on
>> this list. On the other hand, I remember several discussions where
>> people asked if they could write an application and invoke it from
>> SysPrep#### or similar, and the answer has always been, "oh sorry you
>> can't do that, because the lowest level you can go is ShellAppMain(),
>> and that won't work from SysPrep####".
> 
> Huh? Who claimed that? Where?

Sorry, don't have any specifics, just a lingering (but strong) memory.

> (I suspect the meaning of "Application" has taken on some
> overly-specific meaning for someone if they have claimed such - going
> back to how having a proper definition is clearly quite important.)
> 
> Of course they can. Any EDK2 image itself contains a bunch of .efi
> executables - and there is nothing preventing you from invoking those
> from the shell.

The dependency was the other way around. UEFI_APPLICATION modules built
with ShellCEntryLib would depend on the shell to function, and the shell
was not available when the boot manager launched the apps via SysPrep####.

This argument actually makes sense to me; I'm not positing that
ShellCEntryLib apps "should" work in the above situation. The problem is
that the functional alternative (UefiApplicationEntryPoint) has been
super difficult to learn about (from my personal POV anyway).

> And don't forget most platforms ship without a built-in Shell,

correct

> so there would be no way of running ... anything ... if that was true.

It would be more precise to put this as,

  there would be no way of running any *application*, built with *edk2*,
  directly from the *boot manager*

and that had been my exact mental image until I read this thread.

> Also, it's pretty much the whole point of gnu-efi (combined with doing
> it directly in a normal POSIX environment).

I agree 100%, and I didn't forget about shim, grub, or gnu-efi -- please
note the emphasis on "edk2" in my above reformulation.

Thanks
Laszlo

Re: [RFC] Proposal to add edk2-apps repository

[David F.]

I think leaving it in is fine, it is its own directory and everything will
build with the build tools, when you start separating it, it may not build
so easily.   It already take a bit of processing and scripting to compile
full blown apps ported to run on the direct UEFI platform (as well as BIOS,
DOS, Linux, WIndows, etc..).


On Mon, Dec 3, 2018 at 9:10 AM Laszlo Ersek <lersek@redhat.com> wrote:

> On 12/03/18 16:07, Leif Lindholm wrote:
> > On Mon, Dec 03, 2018 at 03:11:33PM +0100, Laszlo Ersek wrote:
> >> On 11/30/18 07:03, Andrew Fish wrote:
> >>> Mike,
> >>>
> >>> As Krishna points out there are flavors of Apps. Do we want to have
> >>> different packages for different flavor of apps, or different dirs in
> >>> a more generic App package? Maybe we should define classes of UEFI
> >>> Applications in the README.md and give them a place to live.
> >>
> >> In my opinion, this is absolutely the first step that should be done.
> >
> > Yes please.
> >
> >> Personally, I've just learned, from this thread, that there are *three*
> >> (not two) UEFI application entry point types that edk2 supports.
> >>
> >> * I've always known about main() -- libc app --, and ShellAppMain() --
> >>   shell app. I've always known these because I read about them in
> >>   "AppPkg/ReadMe.txt" and "StdLib/ReadMe.txt" years ago. In particular,
> >>   compare the description of "Hello" and "Main".
> >>
> >> * And now MdeModulePkg/Application has been mentioned, in this thread,
> >>   where I see UefiMain() as the entry point.
> >
> > Well, these are defined by the application .inf though, so "UefiMain"
> > is just a common name picked. MdeModulePkg/Application also has
> > applications with entry points called 'BootManagerMenuEntry',
> > 'SmiHandlerProfileInfoEntrypoint' and 'InitializeUserInterface'. (The
> > latter being UiApp.)
>
> Right, I guess I should have referred to the "UefiApplicationEntryPoint"
> lib class instead. (I did so below.)
>
> >
> >> I don't recall reading about UefiMain() or UefiApplicationEntryPoint on
> >> this list. On the other hand, I remember several discussions where
> >> people asked if they could write an application and invoke it from
> >> SysPrep#### or similar, and the answer has always been, "oh sorry you
> >> can't do that, because the lowest level you can go is ShellAppMain(),
> >> and that won't work from SysPrep####".
> >
> > Huh? Who claimed that? Where?
>
> Sorry, don't have any specifics, just a lingering (but strong) memory.
>
> > (I suspect the meaning of "Application" has taken on some
> > overly-specific meaning for someone if they have claimed such - going
> > back to how having a proper definition is clearly quite important.)
> >
> > Of course they can. Any EDK2 image itself contains a bunch of .efi
> > executables - and there is nothing preventing you from invoking those
> > from the shell.
>
> The dependency was the other way around. UEFI_APPLICATION modules built
> with ShellCEntryLib would depend on the shell to function, and the shell
> was not available when the boot manager launched the apps via SysPrep####.
>
> This argument actually makes sense to me; I'm not positing that
> ShellCEntryLib apps "should" work in the above situation. The problem is
> that the functional alternative (UefiApplicationEntryPoint) has been
> super difficult to learn about (from my personal POV anyway).
>
> > And don't forget most platforms ship without a built-in Shell,
>
> correct
>
> > so there would be no way of running ... anything ... if that was true.
>
> It would be more precise to put this as,
>
>   there would be no way of running any *application*, built with *edk2*,
>   directly from the *boot manager*
>
> and that had been my exact mental image until I read this thread.
>
> > Also, it's pretty much the whole point of gnu-efi (combined with doing
> > it directly in a normal POSIX environment).
>
> I agree 100%, and I didn't forget about shim, grub, or gnu-efi -- please
> note the emphasis on "edk2" in my above reformulation.
>
> Thanks
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>

Re: [RFC] Proposal to add edk2-apps repository

[Ni, Ruiyu]

Mike,
It's a great idea to have another edk2-apps repo.

I have a question not quite related to this new repo but related to edk2-platforms repo.
There are many platforms in edk2 repo as well, like Ovmf, Emulator, Vlv2TbltDevicePkg.
What's your opinion/plan about these platforms?


> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Friday, November 30, 2018 1:58 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
> Subject: [edk2] [RFC] Proposal to add edk2-apps repository
> 
> Hello,
> 
> I would like to propose the creation of a new repository called edk2-apps.  This
> repository would initially be used to host the following packages from the edk2
> repository:
> 
> * AppPkg
> * StdLib
> * StdLibPrivateInternalFiles
> 
> These 3 packages provide support for the libc along with applications that
> depend on libc.  None of the other packages in the edk2 repository use these
> packages, so these 3 package can be safely moved without any impacts to
> platform firmware builds.
> Build configurations that do use libc features can clone the edk2-apps repository
> and add it to PACKAGES_PATH.
> 
> The history of these 3 packages would be preserved when importing the content
> into edk2-apps.  After The import is verified, these 3 packages would be deleted
> from the edk2 repository.
> 
> This proposal helps reduce the size of the edk2 repository and focuses edk2
> repository on packages used to provide UEFI/PI conformant firmware.
> 
> If there are no concerns with this proposal, I will enter a Tianocore BZs for the
> two steps.
> 
> Best regards,
> 
> Mike
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] Proposal to add edk2-apps repository

[Kinney, Michael D]

Ray,

Real HW platforms like Vlv2* and Quark* should be moved to
edk2-platforms.  Virtual platforms such as Ovmf and EmulatorPkg
should stay in edk2 repo to support validation.

We should enter Tianocore BZ to move the real HW platforms.

Thanks,

Mike

> -----Original Message-----
> From: Ni, Ruiyu
> Sent: Thursday, November 29, 2018 7:32 PM
> To: edk2-devel@lists.01.org; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Subject: RE: [RFC] Proposal to add edk2-apps repository
> 
> Mike,
> It's a great idea to have another edk2-apps repo.
> 
> I have a question not quite related to this new repo but
> related to edk2-platforms repo.
> There are many platforms in edk2 repo as well, like Ovmf,
> Emulator, Vlv2TbltDevicePkg.
> What's your opinion/plan about these platforms?
> 
> 
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-
> bounces@lists.01.org] On Behalf Of
> > Kinney, Michael D
> > Sent: Friday, November 30, 2018 1:58 AM
> > To: edk2-devel@lists.01.org; Kinney, Michael D
> <michael.d.kinney@intel.com>
> > Subject: [edk2] [RFC] Proposal to add edk2-apps
> repository
> >
> > Hello,
> >
> > I would like to propose the creation of a new repository
> called edk2-apps.  This
> > repository would initially be used to host the following
> packages from the edk2
> > repository:
> >
> > * AppPkg
> > * StdLib
> > * StdLibPrivateInternalFiles
> >
> > These 3 packages provide support for the libc along with
> applications that
> > depend on libc.  None of the other packages in the edk2
> repository use these
> > packages, so these 3 package can be safely moved without
> any impacts to
> > platform firmware builds.
> > Build configurations that do use libc features can clone
> the edk2-apps repository
> > and add it to PACKAGES_PATH.
> >
> > The history of these 3 packages would be preserved when
> importing the content
> > into edk2-apps.  After The import is verified, these 3
> packages would be deleted
> > from the edk2 repository.
> >
> > This proposal helps reduce the size of the edk2
> repository and focuses edk2
> > repository on packages used to provide UEFI/PI
> conformant firmware.
> >
> > If there are no concerns with this proposal, I will
> enter a Tianocore BZs for the
> > two steps.
> >
> > Best regards,
> >
> > Mike
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] Proposal to add edk2-apps repository

[Laszlo Ersek]

On 11/30/18 05:57, Kinney, Michael D wrote:

> Virtual platforms such as Ovmf and EmulatorPkg should stay in edk2
> repo to support validation.

Yes, and ArmVirtPkg too.

Thanks,
Laszlo