[RFC v2] Proposal to add edk2-libc

[RFC v2] Proposal to add edk2-libc

[Kinney, Michael D]

Hello,

I shared an RFC in November to add an edk2-apps repository.

https://lists.01.org/pipermail/edk2-devel/2018-November/033330.html

Feedback in this thread discussed that there are three types
of applications.  Apps that use libc, UEFI Shell apps,
and UEFI Applications.  I would like this RFC to focus on libc
applications, and changes related to UEFI Shell apps and
UEFI Applications can be handled separately.  The updated
RFC is shown below.  The repo name has been changed from
edk2-apps to edk2-libc based on feedback from Leif.

============================================================

I would like to propose the creation of a new
repository called edk2-libc.  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-libc repository and add it to
PACKAGES_PATH.

The history of these 3 packages would be preserved
when importing the content into edk2-libc.  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 v2] Proposal to add edk2-libc

[Laszlo Ersek]

On 01/16/19 19:57, Kinney, Michael D wrote:
> Hello,
> 
> I shared an RFC in November to add an edk2-apps repository.
> 
> https://lists.01.org/pipermail/edk2-devel/2018-November/033330.html
> 
> Feedback in this thread discussed that there are three types
> of applications.  Apps that use libc, UEFI Shell apps,
> and UEFI Applications.  I would like this RFC to focus on libc
> applications, and changes related to UEFI Shell apps and
> UEFI Applications can be handled separately.  The updated
> RFC is shown below.  The repo name has been changed from
> edk2-apps to edk2-libc based on feedback from Leif.
> 
> ============================================================
> 
> I would like to propose the creation of a new
> repository called edk2-libc.  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-libc repository and add it to
> PACKAGES_PATH.
> 
> The history of these 3 packages would be preserved
> when importing the content into edk2-libc.  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.

It sounds good to me:

- PACKAGES_PATH is a useful feature and it works well in my experience,
so I think having to use PACKAGES_PATH for pulling in edk2-libc should
not be a large obstacle.

- I'm not sure how closely the StdLib internals are tied to day-to-day
changes in core edk2; that is, whether we should keep those histories
interlinked. That's something for the StdLib maintainers to evaluate.
Personally I don't remember many StdLib changes, so there seems to be a
genuine separation that supports the new repo idea.

Thanks,
Laszlo