"StdLibPkg" branch on edk2-staging

"StdLibPkg" branch on edk2-staging

[Maciej Rabeda]

Hi,

I have submitted a new edk2-staging branch named "StdLibPkg".
https://github.com/tianocore/edk2-staging/tree/StdLibPkg

Branch contains initial implementation of C standard library and 
intrinsic library for UEFI to smoothen open-source submodule integration 
(instead of implementing those functions in each new package introducing 
an external submodule dependent on C stdlib).

More details on the package, its contents and feature scope are placed 
in that branch, in StdLibPkg/Readme.md file.
https://github.com/tianocore/edk2-staging/blob/StdLibPkg/StdLibPkg/Readme.md

Feel free to play around. Any and all feedback is welcome.

Thanks,
Maciej

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Rebecca Cran]

Are you aware of the edk2-libc project at 
https://github.com/tianocore/edk2-libc ?


-- 
Rebecca Cran


On 7/27/21 9:48 AM, Maciej Rabeda wrote:
> Hi,
>
> I have submitted a new edk2-staging branch named "StdLibPkg".
> https://github.com/tianocore/edk2-staging/tree/StdLibPkg
>
> Branch contains initial implementation of C standard library and 
> intrinsic library for UEFI to smoothen open-source submodule 
> integration (instead of implementing those functions in each new 
> package introducing an external submodule dependent on C stdlib).
>
> More details on the package, its contents and feature scope are placed 
> in that branch, in StdLibPkg/Readme.md file.
> https://github.com/tianocore/edk2-staging/blob/StdLibPkg/StdLibPkg/Readme.md 
>
>
> Feel free to play around. Any and all feedback is welcome.
>
> Thanks,
> Maciej
>
>
> 
>
>

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Maciej Rabeda]

Naturally. Since it is there, why is it not used for brotli, openssl in 
CryptoPkg or jansson in RedfishPkg?

On 28-Jul-21 17:34, Rebecca Cran wrote:
> Are you aware of the edk2-libc project at 
> https://github.com/tianocore/edk2-libc ?
>
>

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Rebecca Cran]

I think it's mostly been abandoned, and people are expected to use 
native UEFI functions instead. Personally I'd like to see it continue to 
be maintained.


-- 
Rebecca Cran


On 7/28/21 9:45 AM, Maciej Rabeda wrote:
> Naturally. Since it is there, why is it not used for brotli, openssl 
> in CryptoPkg or jansson in RedfishPkg?
>
> On 28-Jul-21 17:34, Rebecca Cran wrote:
>> Are you aware of the edk2-libc project at 
>> https://github.com/tianocore/edk2-libc ?
>>
>>
>
>
>
> 
>
>

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Tim Lewis]

I would point out that there was significant work on libc in the past (see https://github.com/andreiw/UefiToolsPkg) but never any help to upstream these fixes, including making sure that many Linux tools can easily be ported. I myself have used it to port several BSD utilities over, but each time there will little nits with the existing port and even small patches were returned with "no current maintainer"

In terms of making other projects use libc, I think the other objection was that it was never optimized for non-shell usage. Other projects (lie https://github.com/tianocore/edk2-staging/tree/CdePkg ) have tried to remedy this, but never with source checked in. But it allows support under PEI, DXE, etc.

Tim

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
Sent: Wednesday, July 28, 2021 8:34 AM
To: devel@edk2.groups.io; maciej.rabeda@linux.intel.com
Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

Are you aware of the edk2-libc project at https://github.com/tianocore/edk2-libc ?


-- 
Rebecca Cran


On 7/27/21 9:48 AM, Maciej Rabeda wrote:
> Hi,
>
> I have submitted a new edk2-staging branch named "StdLibPkg".
> https://github.com/tianocore/edk2-staging/tree/StdLibPkg
>
> Branch contains initial implementation of C standard library and 
> intrinsic library for UEFI to smoothen open-source submodule 
> integration (instead of implementing those functions in each new 
> package introducing an external submodule dependent on C stdlib).
>
> More details on the package, its contents and feature scope are placed 
> in that branch, in StdLibPkg/Readme.md file.
> https://github.com/tianocore/edk2-staging/blob/StdLibPkg/StdLibPkg/Readme.md 
>
>
> Feel free to play around. Any and all feedback is welcome.
>
> Thanks,
> Maciej
>
>
> 
>
>

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Rebecca Cran]

CC'ing the Tianocore stewards.


I've had problems getting a recent patch committed just to make 
edk2-libc work against current edk2 master.

Tianocore stewards: do we need new or additional maintainers for 
edk2-libc, or is there a plan to deprecate it?


The current maintainers are listed as:

StdLib, StdLibPrivateInternalFiles
W: https://github.com/tianocore/tianocore.github.io/wiki/StdLib
M: Daryl McDaniel <edk2-lists@mc2research.org>
M: Jaben Carsey <jaben.carsey@intel.com>


-- 
Rebecca Cran


On 7/28/21 4:25 PM, tim.lewis@insyde.com wrote:
> I would point out that there was significant work on libc in the past (see https://github.com/andreiw/UefiToolsPkg) but never any help to upstream these fixes, including making sure that many Linux tools can easily be ported. I myself have used it to port several BSD utilities over, but each time there will little nits with the existing port and even small patches were returned with "no current maintainer"
>
> In terms of making other projects use libc, I think the other objection was that it was never optimized for non-shell usage. Other projects (lie https://github.com/tianocore/edk2-staging/tree/CdePkg ) have tried to remedy this, but never with source checked in. But it allows support under PEI, DXE, etc.
>
> Tim
>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
> Sent: Wednesday, July 28, 2021 8:34 AM
> To: devel@edk2.groups.io; maciej.rabeda@linux.intel.com
> Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging
>
> Are you aware of the edk2-libc project at https://github.com/tianocore/edk2-libc ?
>
>

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Leif Lindholm]

Hi Rebecca,

I think the truth is we're a bit resigned about edk2-libc in general.
My view is it should be either maintained or deprecated (or replaced).

And maintainership *should* mean at least keeping it up to date with
security fixes.

I personally have no enthusiasm for the topic, but if there existed:
- An up-to-date codebase.
- A plan for keeping the coodbase up-to-date (as opposed to a plan to
  keep the codebase up-to-date).
- At least a couple of maintainers.
I would have no objection to that existing under the TianoCore
umbrella.

Best Regards,

Leif

On Wed, Jul 28, 2021 at 16:44:02 -0600, Rebecca Cran wrote:
> CC'ing the Tianocore stewards.
> 
> 
> I've had problems getting a recent patch committed just to make edk2-libc
> work against current edk2 master.
> 
> Tianocore stewards: do we need new or additional maintainers for edk2-libc,
> or is there a plan to deprecate it?
> 
> 
> The current maintainers are listed as:
> 
> StdLib, StdLibPrivateInternalFiles
> W: https://github.com/tianocore/tianocore.github.io/wiki/StdLib
> M: Daryl McDaniel <edk2-lists@mc2research.org>
> M: Jaben Carsey <jaben.carsey@intel.com>
> 
> 
> -- 
> Rebecca Cran
> 
> 
> On 7/28/21 4:25 PM, tim.lewis@insyde.com wrote:
> > I would point out that there was significant work on libc in the
> past (see https://github.com/andreiw/UefiToolsPkg) but never any
> help to upstream these fixes, including making sure that many Linux
> tools can easily be ported. I myself have used it to port several
> BSD utilities over, but each time there will little nits with the
> existing port and even small patches were returned with "no current
> maintainer"
> > 
> > In terms of making other projects use libc, I think the other
> > objection was that it was never optimized for non-shell
> > usage. Other projects (lie
> > https://github.com/tianocore/edk2-staging/tree/CdePkg ) have tried
> > to remedy this, but never with source checked in. But it allows
> > support under PEI, DXE, etc.
> > 
> > Tim
> > 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
> > Sent: Wednesday, July 28, 2021 8:34 AM
> > To: devel@edk2.groups.io; maciej.rabeda@linux.intel.com
> > Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging
> > 
> > Are you aware of the edk2-libc project at https://github.com/tianocore/edk2-libc ?
> > 
> > 

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Andrew Fish]

I’d guess I’d also ask the why not NewLib? Especially since Red Hat helps out with edk2….

Thanks,

Andrew Fish

> On Aug 4, 2021, at 4:03 AM, Leif Lindholm <leif@nuviainc.com> wrote:
> 
> Hi Rebecca,
> 
> I think the truth is we're a bit resigned about edk2-libc in general.
> My view is it should be either maintained or deprecated (or replaced).
> 
> And maintainership *should* mean at least keeping it up to date with
> security fixes.
> 
> I personally have no enthusiasm for the topic, but if there existed:
> - An up-to-date codebase.
> - A plan for keeping the coodbase up-to-date (as opposed to a plan to
>  keep the codebase up-to-date).
> - At least a couple of maintainers.
> I would have no objection to that existing under the TianoCore
> umbrella.
> 
> Best Regards,
> 
> Leif
> 
> On Wed, Jul 28, 2021 at 16:44:02 -0600, Rebecca Cran wrote:
>> CC'ing the Tianocore stewards.
>> 
>> 
>> I've had problems getting a recent patch committed just to make edk2-libc
>> work against current edk2 master.
>> 
>> Tianocore stewards: do we need new or additional maintainers for edk2-libc,
>> or is there a plan to deprecate it?
>> 
>> 
>> The current maintainers are listed as:
>> 
>> StdLib, StdLibPrivateInternalFiles
>> W: https://github.com/tianocore/tianocore.github.io/wiki/StdLib
>> M: Daryl McDaniel <edk2-lists@mc2research.org>
>> M: Jaben Carsey <jaben.carsey@intel.com>
>> 
>> 
>> -- 
>> Rebecca Cran
>> 
>> 
>> On 7/28/21 4:25 PM, tim.lewis@insyde.com wrote:
>>> I would point out that there was significant work on libc in the
>> past (see https://github.com/andreiw/UefiToolsPkg) but never any
>> help to upstream these fixes, including making sure that many Linux
>> tools can easily be ported. I myself have used it to port several
>> BSD utilities over, but each time there will little nits with the
>> existing port and even small patches were returned with "no current
>> maintainer"
>>> 
>>> In terms of making other projects use libc, I think the other
>>> objection was that it was never optimized for non-shell
>>> usage. Other projects (lie
>>> https://github.com/tianocore/edk2-staging/tree/CdePkg ) have tried
>>> to remedy this, but never with source checked in. But it allows
>>> support under PEI, DXE, etc.
>>> 
>>> Tim
>>> 
>>> -----Original Message-----
>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
>>> Sent: Wednesday, July 28, 2021 8:34 AM
>>> To: devel@edk2.groups.io; maciej.rabeda@linux.intel.com
>>> Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging
>>> 
>>> Are you aware of the edk2-libc project at https://github.com/tianocore/edk2-libc ?
>>> 
>>> 
> 
> 
> 
> 
> 

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Kilian Kegel]

[-- Attachment #1: Type: text/plain, Size: 6696 bytes --]

Hi all,

I plan to come back with the https://github.com/tianocore/edk2-staging/tree/CdePkg end of this year
and to unroll the source code of fundamental parts of my C Library and discuss that along
the 30. anniversary of “The C Book” https://publications.gbdirect.co.uk/c_book/chapter9

Additionally I will discuss the details you need to know:

  1.  about the differences C90/C95/C99 in language and library
  2.  how to get HOSTED ENVIRONMENT for UEFI POST drivers
  3.  how to get Intel/AMD TimeStampCounter based precise time calibration - platform,

processor  and chipset independent for x86 UEFI platforms

  1.  how to arrange space optimization for UEFI FW as an embedded platform
  2.  how to test and verify the compatibility of a Standard C Library implementation,

since “CI“ won’t help at all in this regards

  1.  how to implement a printf-core that performs narrow and wide mode at once for space optimization
  2.  how to implement a scanf-core that performs narrow and wide mode at once for space optimization
  3.  how to implement realloc() sub-allocator on UEFI memory management functions for PEI and DXE

Note: If UEFI is going to provide Standard-C-Functions for all drivers, you will have soon e.g. “sprintf()”
in all drivers. The amount of code for a proper sprintf() + scanf() + wscanf() + strtok() + wcstok() + malloc() … implementation
that is not tailored for embedded FW, will overrun the BIOS FLASH space instantly.
I consider commercial BIOS implementations that runs really many drivers (> 100) to start a platform.


Currently I implement more feature to CdePkg/Torito C Library:

  1.  Improve UEFI driver cross development for VisualStudio and EDK2
  2.  substitution of “DEBUG” traces by CdePkg-traces

that allows usage of predefined DEBUG-messages to run in a CdePkg-based driver.



Sole purpose is to have DEBUG/RELEASE mode _NOT_ globally, but locally to get

trace messages selectively for specific drivers only.

(to speed up POST with traces, that consumes a significant amount of time during

working hours of a BIOS developer)



  1.  add SMM support.

Shell, DXE, PEI (pre and post memory) is already available for 2 years:
https://edk2.groups.io/g/devel/message/51562?p=,,,20,0,0,0::Created,,CdePkg,20,2,0,65191785



  1.  get ACPICA tools https://acpica.org/ to UEFI Shell



I need to implement some non-standard / Microsoft specific C functions

to get that running for Andrew Fish.

That time links from https://github.com/KilianKegel are under construction and are
not necessarily  up-to-date.
Same for https://github.com/tianocore/edk2-staging/tree/CdePkg that is not used for long …

But https://github.com/KilianKegel/CdePkg.git driver set and sample set runs instantly
on the latest BIOS of a commercial vendor on a Intel IOTG TGL-H (Tiger Lake H) board using the Microsoft
build environment.

@Tim: I’d really appreciate if CdePkg could hold additionally Insyde BIOS support. Regrettably
I do not have access to Insyde source code.

@Maciej
I can not see any “wide” functions here. https://github.com/DevSolar/pdclib<https://github.com/DevSolar/pdclib%20from%20WCHAR.H>
from WCHAR.H or WCTYPE.H. That is a serious limitation in the UEFI environment.

To create UEFI-Shell programs for Personal Computers this link can be used.
https://github.com/KilianKegel/Visual-ANSI-C-for-UEFI-Shell#visual-ansi-c-for-uefi-shell

Best regards,
Kilian

From: Andrew Fish via groups.io<mailto:afish=apple.com@groups.io>
Sent: Thursday, August 5, 2021 05:35 AM
To: edk2-devel-groups-io<mailto:devel@edk2.groups.io>; Leif Lindholm<mailto:leif@nuviainc.com>
Cc: Rebecca Cran<mailto:rebecca@nuviainc.com>; tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>; maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>; Mike Kinney<mailto:michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

I’d guess I’d also ask the why not NewLib? Especially since Red Hat helps out with edk2….

Thanks,

Andrew Fish

> On Aug 4, 2021, at 4:03 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>
> Hi Rebecca,
>
> I think the truth is we're a bit resigned about edk2-libc in general.
> My view is it should be either maintained or deprecated (or replaced).
>
> And maintainership *should* mean at least keeping it up to date with
> security fixes.
>
> I personally have no enthusiasm for the topic, but if there existed:
> - An up-to-date codebase.
> - A plan for keeping the coodbase up-to-date (as opposed to a plan to
>  keep the codebase up-to-date).
> - At least a couple of maintainers.
> I would have no objection to that existing under the TianoCore
> umbrella.
>
> Best Regards,
>
> Leif
>
> On Wed, Jul 28, 2021 at 16:44:02 -0600, Rebecca Cran wrote:
>> CC'ing the Tianocore stewards.
>>
>>
>> I've had problems getting a recent patch committed just to make edk2-libc
>> work against current edk2 master.
>>
>> Tianocore stewards: do we need new or additional maintainers for edk2-libc,
>> or is there a plan to deprecate it?
>>
>>
>> The current maintainers are listed as:
>>
>> StdLib, StdLibPrivateInternalFiles
>> W: https://github.com/tianocore/tianocore.github.io/wiki/StdLib
>> M: Daryl McDaniel <edk2-lists@mc2research.org>
>> M: Jaben Carsey <jaben.carsey@intel.com>
>>
>>
>> --
>> Rebecca Cran
>>
>>
>> On 7/28/21 4:25 PM, tim.lewis@insyde.com wrote:
>>> I would point out that there was significant work on libc in the
>> past (see https://github.com/andreiw/UefiToolsPkg) but never any
>> help to upstream these fixes, including making sure that many Linux
>> tools can easily be ported. I myself have used it to port several
>> BSD utilities over, but each time there will little nits with the
>> existing port and even small patches were returned with "no current
>> maintainer"
>>>
>>> In terms of making other projects use libc, I think the other
>>> objection was that it was never optimized for non-shell
>>> usage. Other projects (lie
>>> https://github.com/tianocore/edk2-staging/tree/CdePkg ) have tried
>>> to remedy this, but never with source checked in. But it allows
>>> support under PEI, DXE, etc.
>>>
>>> Tim
>>>
>>> -----Original Message-----
>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
>>> Sent: Wednesday, July 28, 2021 8:34 AM
>>> To: devel@edk2.groups.io; maciej.rabeda@linux.intel.com
>>> Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging
>>>
>>> Are you aware of the edk2-libc project at https://github.com/tianocore/edk2-libc ?
>>>
>>>
>
>
>
>
>







[-- Attachment #2: Type: text/html, Size: 16314 bytes --]

Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

[Kilian Kegel]

[-- Attachment #1.1: Type: text/plain, Size: 8065 bytes --]

Hi Maciej,

I have updated and fixed build errors in branch CdePkg (https://github.com/tianocore/edk2-staging.git).

Also a POST trace is recorded on my MinnowBoard and stored here:
https://raw.githubusercontent.com/tianocore/edk2-staging/CdePkg/UEFIBinaries/RELEASE.log
All implemented Standard-C-functions from CdePkg/Torito C Library demonstrates
its basic behavior.
There are also a lot of WCHAR.H- and WCTYPE.H-functions.
For the wide-functions I just perform the characters 0..0x1FF instead of all 65536
different wchar_t characters due to runtime regards…

Regrettably the MinnowBoard is deprecated https://www.silicom-usa.com/pr/eol/minnowboard-turbot<https://www.silicom-usa.com/pr/eol/minnowboard-turbot/>
but the CdePkg also runs in the EMULATOR: https://github.com/tianocore/edk2-staging/tree/CdePkg#howto

Best Regards,
Kilian
From: Kilian Kegel<mailto:kilian_kegel@outlook.com>
Sent: Thursday, August 5, 2021 06:14 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; afish@apple.com<mailto:afish@apple.com>; Leif Lindholm<mailto:leif@nuviainc.com>
Cc: Rebecca Cran<mailto:rebecca@nuviainc.com>; tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>; maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>; Mike Kinney<mailto:michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

Hi all,

I plan to come back with the https://github.com/tianocore/edk2-staging/tree/CdePkg end of this year
and to unroll the source code of fundamental parts of my C Library and discuss that along
the 30. anniversary of “The C Book” https://publications.gbdirect.co.uk/c_book/chapter9

Additionally I will discuss the details you need to know:

  1.  about the differences C90/C95/C99 in language and library
  2.  how to get HOSTED ENVIRONMENT for UEFI POST drivers
  3.  how to get Intel/AMD TimeStampCounter based precise time calibration - platform,

processor  and chipset independent for x86 UEFI platforms

  1.  how to arrange space optimization for UEFI FW as an embedded platform
  2.  how to test and verify the compatibility of a Standard C Library implementation,

since “CI“ won’t help at all in this regards

  1.  how to implement a printf-core that performs narrow and wide mode at once for space optimization
  2.  how to implement a scanf-core that performs narrow and wide mode at once for space optimization
  3.  how to implement realloc() sub-allocator on UEFI memory management functions for PEI and DXE

Note: If UEFI is going to provide Standard-C-Functions for all drivers, you will have soon e.g. “sprintf()”
in all drivers. The amount of code for a proper sprintf() + scanf() + wscanf() + strtok() + wcstok() + malloc() … implementation
that is not tailored for embedded FW, will overrun the BIOS FLASH space instantly.
I consider commercial BIOS implementations that runs really many drivers (> 100) to start a platform.


Currently I implement more feature to CdePkg/Torito C Library:

  1.  Improve UEFI driver cross development for VisualStudio and EDK2
  2.  substitution of “DEBUG” traces by CdePkg-traces

that allows usage of predefined DEBUG-messages to run in a CdePkg-based driver.



Sole purpose is to have DEBUG/RELEASE mode _NOT_ globally, but locally to get

trace messages selectively for specific drivers only.

(to speed up POST with traces, that consumes a significant amount of time during

working hours of a BIOS developer)



  1.  add SMM support.

Shell, DXE, PEI (pre and post memory) is already available for 2 years:
https://edk2.groups.io/g/devel/message/51562?p=,,,20,0,0,0::Created,,CdePkg,20,2,0,65191785



  1.  get ACPICA tools https://acpica.org/ to UEFI Shell



I need to implement some non-standard / Microsoft specific C functions

to get that running for Andrew Fish.

That time links from https://github.com/KilianKegel are under construction and are
not necessarily  up-to-date.
Same for https://github.com/tianocore/edk2-staging/tree/CdePkg that is not used for long …

But https://github.com/KilianKegel/CdePkg.git driver set and sample set runs instantly
on the latest BIOS of a commercial vendor on a Intel IOTG TGL-H (Tiger Lake H) board using the Microsoft
build environment.

@Tim: I’d really appreciate if CdePkg could hold additionally Insyde BIOS support. Regrettably
I do not have access to Insyde source code.

@Maciej
I can not see any “wide” functions here. https://github.com/DevSolar/pdclib<https://github.com/DevSolar/pdclib%20from%20WCHAR.H>
from WCHAR.H or WCTYPE.H. That is a serious limitation in the UEFI environment.

To create UEFI-Shell programs for Personal Computers this link can be used.
https://github.com/KilianKegel/Visual-ANSI-C-for-UEFI-Shell#visual-ansi-c-for-uefi-shell

Best regards,
Kilian

From: Andrew Fish via groups.io<mailto:afish=apple.com@groups.io>
Sent: Thursday, August 5, 2021 05:35 AM
To: edk2-devel-groups-io<mailto:devel@edk2.groups.io>; Leif Lindholm<mailto:leif@nuviainc.com>
Cc: Rebecca Cran<mailto:rebecca@nuviainc.com>; tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>; maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>; Mike Kinney<mailto:michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging

I’d guess I’d also ask the why not NewLib? Especially since Red Hat helps out with edk2….

Thanks,

Andrew Fish

> On Aug 4, 2021, at 4:03 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>
> Hi Rebecca,
>
> I think the truth is we're a bit resigned about edk2-libc in general.
> My view is it should be either maintained or deprecated (or replaced).
>
> And maintainership *should* mean at least keeping it up to date with
> security fixes.
>
> I personally have no enthusiasm for the topic, but if there existed:
> - An up-to-date codebase.
> - A plan for keeping the coodbase up-to-date (as opposed to a plan to
>  keep the codebase up-to-date).
> - At least a couple of maintainers.
> I would have no objection to that existing under the TianoCore
> umbrella.
>
> Best Regards,
>
> Leif
>
> On Wed, Jul 28, 2021 at 16:44:02 -0600, Rebecca Cran wrote:
>> CC'ing the Tianocore stewards.
>>
>>
>> I've had problems getting a recent patch committed just to make edk2-libc
>> work against current edk2 master.
>>
>> Tianocore stewards: do we need new or additional maintainers for edk2-libc,
>> or is there a plan to deprecate it?
>>
>>
>> The current maintainers are listed as:
>>
>> StdLib, StdLibPrivateInternalFiles
>> W: https://github.com/tianocore/tianocore.github.io/wiki/StdLib
>> M: Daryl McDaniel <edk2-lists@mc2research.org>
>> M: Jaben Carsey <jaben.carsey@intel.com>
>>
>>
>> --
>> Rebecca Cran
>>
>>
>> On 7/28/21 4:25 PM, tim.lewis@insyde.com wrote:
>>> I would point out that there was significant work on libc in the
>> past (see https://github.com/andreiw/UefiToolsPkg) but never any
>> help to upstream these fixes, including making sure that many Linux
>> tools can easily be ported. I myself have used it to port several
>> BSD utilities over, but each time there will little nits with the
>> existing port and even small patches were returned with "no current
>> maintainer"
>>>
>>> In terms of making other projects use libc, I think the other
>>> objection was that it was never optimized for non-shell
>>> usage. Other projects (lie
>>> https://github.com/tianocore/edk2-staging/tree/CdePkg ) have tried
>>> to remedy this, but never with source checked in. But it allows
>>> support under PEI, DXE, etc.
>>>
>>> Tim
>>>
>>> -----Original Message-----
>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca Cran
>>> Sent: Wednesday, July 28, 2021 8:34 AM
>>> To: devel@edk2.groups.io; maciej.rabeda@linux.intel.com
>>> Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging
>>>
>>> Are you aware of the edk2-libc project at https://github.com/tianocore/edk2-libc ?
>>>
>>>
>
>
>
>
>








[-- Attachment #1.2: Type: text/html, Size: 19181 bytes --]

[-- Attachment #2: 91D6A18A388446A38691886DAE994FEF.png --]
[-- Type: image/png, Size: 132 bytes --]

CdePkgBlog 2021-11-14

[Kilian Kegel]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Hi All,

as announced last summer, I’d like to start a comprehensive tutorial on
how to use Standard C / ANSI C in the UEFI environment and how to design and implement
such a library for Shell and POST usage.

Since most parts of that comprehensive work are already done,
I will report, demonstrate and discuss implementation principles and details on edk2.groups.io
as a kind of “blog” on a biweekly basis.

Please checkout my first CdePkgBlog https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-11-14#cdepkgblog-2021-11-14
and enjoy the breathtaking build speed if compiler and linker are used exclusively to create MY LEGACY TOOLBOX,
a handy set of one-trick-ponies that I have been using for about 25 years.

Have fun,
Kilian


[-- Attachment #2: Type: text/html, Size: 5288 bytes --]

Re: [edk2-devel] CdePkgBlog 2021-11-14

[Maciej Rabeda]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

Hi Kilian,

 From my point of view, the main problem with adoption of CdePkg to EDK2 
is that it relies on Torito C library.

 1. Torito C library License
    (https://github.com/KilianKegel/toro-C-Library/blob/master/LICENSE.md)
    only allows for creating UEFI Shell applications.
      * What about applications that do not rely on ShellPkg (example:
        SysPrep application that might want to use Redfish, which
        depends on C standard library)?
      * What about drivers/libraries that rely on C standard library?
      * How is that compatible with EDK2 BSD-2-Clause-Patent?
 2. Torito C is pre-compiled.
      * How can I verify what was actually implemented inside? Industry
        would have to trust your tests, perform own set of tests or/and
        disassemble it (doable, but unacceptable effort-wise).

Unless those problems are solved, I simply cannot use it.

Thanks,
Maciej

On 14-Nov-21 20:51, Kilian Kegel wrote:
>
> Hi All,
>
> as announced last summer, I’d like to start a comprehensive tutorial on
>
> how to use Standard C / ANSI C in the UEFI environment and how to 
> design and implement
>
> such a library for Shell and POST usage.
>
> Since most parts of that comprehensive work are already done,
>
> I will report, demonstrate and discuss implementation principles and 
> details on edk2.groups.io
>
> as a kind of “blog” on a biweekly basis.
>
> Please checkout my first CdePkgBlog 
> https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-11-14#cdepkgblog-2021-11-14
>
> and enjoy the breathtaking build speed if compiler and linker are used 
> exclusively to create MY LEGACY TOOLBOX,
>
> a handy set of one-trick-ponies that I have been using for about 25 years.
>
> Have fun,
>
> Kilian
>
> 

[-- Attachment #2: Type: text/html, Size: 3947 bytes --]

Re: [edk2-devel] CdePkgBlog 2021-11-14

[Kilian Kegel]

[-- Attachment #1.1: Type: text/plain, Size: 4890 bytes --]

Hi Maciej,

CdePkg is already integrated into EDK2 and satisfies all your needs for pre-/post-memory
PEI, DXE, (SMM in latest releases only), BDS and UEFI Shell too.

I have introduced CdePkg for POST usage 2 years ago without any interest of the “Tianocore Community”:
https://edk2.groups.io/g/devel/message/51562?p=,,,20,0,0,0::Created,,CdePkg,20,2,0,65191785


  1.  Klick on the email link above
  2.  Klick on the first link in that email, that goes to the edk2-staging\cdepkg folder



[cid:image001.png@01D7E178.E5854300]

  1.  read the HOWTO: https://github.com/tianocore/edk2-staging/blob/CdePkg/README.md#howto
               and go for emulation – that works perfectly.

  1.  I simply can’t do more for you, than to urgently encourage to try it out yourself, test it, see what it can do for you

This time toro C Library (that is absolutely the same as the library part of the latest
CdePkg https://github.com/KilianKegel/CdePkg/blob/master/CdeLib/CdeLib.mak#L15)
for UEFI Shell will be discussed first, since “Tianocore Community” is now aware of serious problems of edk2libc
and probably ready to examine my solution, that lacks all of those issues.

You, Maciej, can support CdePkg/ toro C Library by


  1.  testing CdePkg
  2.  giving feedback to the community
  3.  updating CdePkg to latest AAEON WhiskeyLake platform (that is on my Desk for months but I simply don’t have time to get it running…)

(MinnowBoard is deprecated now)

The license issue can not be discussed before there is any serious interest in CdePkg and toro C Library.

But if you are seeking  for a free solution, that

  *   requires unknown additional working hours
  *   requires a couple of high motivated maintainers, specialized in Standard C
  *   countless  patches will spam your inbox folder for years
  *   additionally with unpredictable result
please use  edk2libc, PDCLIB or adjust NewLib for your needs.

>Unless those problems are solved, I simply cannot use it.
Right, but you are invited to take a test drive!
In the EDK2 Emulator. Debugging with the best Debugtool ever seen…
Try to get SysPrep and Redfish running in the Emulator.
Really, just do it!

> How can I verify what was actually implemented inside?
I will publish source code of toro C Library beginning 2022 and discuss the design details along those files.
But, did you check glibc’s fopen-source before using it?
Have you ever seen Microsoft/Borland/Symantec/ARM/IBM/Dinkumware/Greenhill/IAR … C Libraries source code?

Thanks,
Kilian


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: Rabeda, Maciej<mailto:maciej.rabeda@linux.intel.com>
Sent: Monday, November 22, 2021 05:31 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; KILIAN_KEGEL@OUTLOOK.COM<mailto:KILIAN_KEGEL@OUTLOOK.COM>
Cc: Rebecca Cran<mailto:rebecca@nuviainc.com>; tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>; Mike Kinney<mailto:michael.d.kinney@intel.com>; afish@apple.com<mailto:afish@apple.com>; Leif Lindholm<mailto:leif@nuviainc.com>; Richardson, Brian<mailto:brian.richardson@intel.com>
Subject: Re: [edk2-devel] CdePkgBlog 2021-11-14

Hi Kilian,

>From my point of view, the main problem with adoption of CdePkg to EDK2 is that it relies on Torito C library.

  1.  Torito C library License (https://github.com/KilianKegel/toro-C-Library/blob/master/LICENSE.md) only allows for creating UEFI Shell applications.
     *   What about applications that do not rely on ShellPkg (example: SysPrep application that might want to use Redfish, which depends on C standard library)?
     *   What about drivers/libraries that rely on C standard library?
     *   How is that compatible with EDK2 BSD-2-Clause-Patent?
  2.  Torito C is pre-compiled.
     *   How can I verify what was actually implemented inside? Industry would have to trust your tests, perform own set of tests or/and disassemble it (doable, but unacceptable effort-wise).

Unless those problems are solved, I simply cannot use it.
Thanks,
Maciej
On 14-Nov-21 20:51, Kilian Kegel wrote:
Hi All,

as announced last summer, I’d like to start a comprehensive tutorial on
how to use Standard C / ANSI C in the UEFI environment and how to design and implement
such a library for Shell and POST usage.

Since most parts of that comprehensive work are already done,
I will report, demonstrate and discuss implementation principles and details on edk2.groups.io
as a kind of “blog” on a biweekly basis.

Please checkout my first CdePkgBlog https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-11-14#cdepkgblog-2021-11-14
and enjoy the breathtaking build speed if compiler and linker are used exclusively to create MY LEGACY TOOLBOX,
a handy set of one-trick-ponies that I have been using for about 25 years.

Have fun,
Kilian





[-- Attachment #1.2: Type: text/html, Size: 17677 bytes --]

[-- Attachment #2: 3F1FECE7AF8044E584BF5D0CF3028E97.png --]
[-- Type: image/png, Size: 13937 bytes --]

[-- Attachment #3: E06AA5DE32A14AE2A4736488BC5EB760.png --]
[-- Type: image/png, Size: 132 bytes --]

Re: [edk2-devel] CdePkgBlog 2021-11-14

[Pedro Falcato]

[-- Attachment #1.1: Type: text/plain, Size: 5849 bytes --]

Hi Kilian,

I agree with Maciej. There should be a big emphasis on getting an
*open-source* libc available in EDK2, and not relying on a proprietary,
opaque binary blob.

In my opinion EDK2 should pivot to using a high-quality, license-compatible
libc such as Newlib, musl, etc. If you believe your Toro C library is the
best tool for the job, you should open-source it (with a compatible
license) as soon as possible to let the community decide :)

Best regards,
Pedro

On Wed, Nov 24, 2021 at 8:21 PM Kilian Kegel <KILIAN_KEGEL@outlook.com>
wrote:

> Hi Maciej,
>
>
>
> *CdePkg* is already integrated into EDK2 and satisfies all your needs for
> pre-/post-memory
>
> PEI, DXE, (SMM in latest releases only), BDS and UEFI Shell too.
>
>
>
> I have introduced *CdePkg* for POST usage 2 years ago without any
> interest of the “Tianocore Community”:
>
>
> https://edk2.groups.io/g/devel/message/51562?p=,,,20,0,0,0::Created,,CdePkg,20,2,0,65191785
>
>
>
>    1. Klick on the email link above
>    2. Klick on the first link in that email, that goes to the
>    edk2-staging\cdepkg folder
>
>
>
>
>    1. read the HOWTO:
>    https://github.com/tianocore/edk2-staging/blob/CdePkg/README.md#howto
>
>                *and go for emulation – that works perfectly.*
>
>    1. I simply can’t do more for you, than to urgently encourage to try
>    it out yourself, test it, see what it can do for you
>
>
>
> This time *toro C Library* (that is absolutely the same as the library
> part of the latest
>
> CdePkg
> https://github.com/KilianKegel/CdePkg/blob/master/CdeLib/CdeLib.mak#L15)
>
> for UEFI Shell will be discussed first, since “Tianocore Community” is now
> aware of serious problems of edk2libc
>
> and probably ready to examine my solution, that lacks all of those issues.
>
>
>
> You, Maciej, can support *CdePkg/ toro C Library* by
>
>
>
>    1. testing *CdePkg*
>    2. giving feedback to the community
>    3. updating *CdePkg* to latest AAEON WhiskeyLake platform (that is on
>    my Desk for months but I simply don’t have time to get it running…)
>
> (MinnowBoard is deprecated now)
>
>
>
> The license issue *can not* be discussed *before* there is any serious
> interest in *CdePkg* and *toro C Library*.
>
>
>
> But if you are seeking  for a free solution, that
>
>    - requires unknown additional working hours
>    - requires a couple of high motivated maintainers, specialized in
>    Standard C
>    - countless  patches will spam your inbox folder for years
>    - additionally with unpredictable result
>
> please use  edk2libc, PDCLIB or adjust NewLib for your needs.
>
>
>
> >Unless those problems are solved, I simply cannot use it.
>
> Right, but you are invited to take a test drive!
>
> In the EDK2 Emulator. Debugging with the best Debugtool ever seen…
>
> Try to get SysPrep and Redfish running in the Emulator.
>
> Really, just do it!
>
>
>
> > How can I verify what was actually implemented inside?
>
> I will publish source code of *toro C Library* beginning 2022 and discuss
> the design details along those files.
>
> But, did you check glibc’s fopen-source before using it?
>
> Have you ever seen
> Microsoft/Borland/Symantec/ARM/IBM/Dinkumware/Greenhill/IAR … C Libraries
> source code?
>
>
>
> Thanks,
>
> Kilian
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows
>
>
>
> *From: *Rabeda, Maciej <maciej.rabeda@linux.intel.com>
> *Sent: *Monday, November 22, 2021 05:31 PM
> *To: *devel@edk2.groups.io; KILIAN_KEGEL@OUTLOOK.COM
> *Cc: *Rebecca Cran <rebecca@nuviainc.com>; tim.lewis@insyde.com; Mike
> Kinney <michael.d.kinney@intel.com>; afish@apple.com; Leif Lindholm
> <leif@nuviainc.com>; Richardson, Brian <brian.richardson@intel.com>
> *Subject: *Re: [edk2-devel] CdePkgBlog 2021-11-14
>
>
>
> Hi Kilian,
>
> From my point of view, the main problem with adoption of CdePkg to EDK2 is
> that it relies on Torito C library.
>
>    1. Torito C library License (
>    https://github.com/KilianKegel/toro-C-Library/blob/master/LICENSE.md)
>    only allows for creating UEFI Shell applications.
>       - What about applications that do not rely on ShellPkg (example:
>       SysPrep application that might want to use Redfish, which depends on C
>       standard library)?
>       - What about drivers/libraries that rely on C standard library?
>       - How is that compatible with EDK2 BSD-2-Clause-Patent?
>    2. Torito C is pre-compiled.
>       - How can I verify what was actually implemented inside? Industry
>       would have to trust your tests, perform own set of tests or/and disassemble
>       it (doable, but unacceptable effort-wise).
>
> Unless those problems are solved, I simply cannot use it.
>
> Thanks,
> Maciej
>
> On 14-Nov-21 20:51, Kilian Kegel wrote:
>
> Hi All,
>
>
>
> as announced last summer, I’d like to start a comprehensive tutorial on
>
> how to use Standard C / ANSI C in the UEFI environment and how to design
> and implement
>
> such a library for Shell and POST usage.
>
>
>
> Since most parts of that comprehensive work are already done,
>
> I will report, demonstrate and discuss implementation principles and
> details on edk2.groups.io
>
> as a kind of “blog” on a biweekly basis.
>
>
>
> Please checkout my first CdePkgBlog
> https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-11-14#cdepkgblog-2021-11-14
>
> and enjoy the breathtaking build speed if compiler and linker are used
> exclusively to create MY LEGACY TOOLBOX,
>
> a handy set of one-trick-ponies that I have been using for about 25 years.
>
>
>
> Have fun,
>
> Kilian
>
>
>
>
>
>
> 
>
>

-- 
Pedro Falcato

[-- Attachment #1.2: Type: text/html, Size: 12195 bytes --]

[-- Attachment #2: 3F1FECE7AF8044E584BF5D0CF3028E97.png --]
[-- Type: image/png, Size: 13937 bytes --]

CdePkgBlog 2021-11-18

[Kilian Kegel]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

Hi All,

as announced in my last CdePkgBlog I’d like to demonstrate how to design, create and build missing
tools for the UEFI Shell, that are still known today from the Windows command line: FIND and MORE.

Along those tools I:

  1.  describe how to deal with native UEFI ASCII and UTF16 files.
  2.  publish toro C Library stdin file/console handling as a part of a reference implementation
  3.  publish toro C Library command-line-to-argc/argv translation as part of a reference implementation
  4.  publish toro C Library concept of how to pass the OS-interface SystemTable to main() in a Standard-C-compatible sideway

Once again the tools were translated to .EFI executables using the Microsoft VisualStudio 2022 command line
without the EDK2 build process.
Please checkout my second CdePkgBlog https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-11-28#cdepkgblog-2021-11-28
and enjoy the breathtaking build speed if compiler and linker are used exclusively to create FIND.EFI and MORE.EFI
Have fun,
Kilian


[-- Attachment #2: Type: text/html, Size: 7780 bytes --]

Re: [edk2-devel] CdePkgBlog 2021-11-14

[Maciej Rabeda]

[-- Attachment #1: Type: text/plain, Size: 5476 bytes --]

Hi Kilian,

CdePkg *has not* been integrated into EDK2. It is simply in 
edk2-staging, and that's a large difference.
As for "satisfies all my needs" - it does not for the reasons I have 
previously outlined.

Reiterating: unless Torito C library is not released as source code 
under an EDK2-compatible license, I cannot use it. Period.

Thanks,
Maciej

On 24-Nov-21 21:21, Kilian Kegel wrote:
>
> Hi Maciej,
>
> *CdePkg* is already integrated into EDK2 and satisfies all your needs 
> for pre-/post-memory
>
> PEI, DXE, (SMM in latest releases only), BDS and UEFI Shell too.
>
> I have introduced *CdePkg* for POST usage 2 years ago without any 
> interest of the “Tianocore Community”:
>
> https://edk2.groups.io/g/devel/message/51562?p=,,,20,0,0,0::Created,,CdePkg,20,2,0,65191785
>
>  1. Klick on the email link above
>  2. Klick on the first link in that email, that goes to the
>     edk2-staging\cdepkg folder
>
>  3. read the HOWTO:
>     https://github.com/tianocore/edk2-staging/blob/CdePkg/README.md#howto
>
> *and go for emulation – that works perfectly.*
>
>  4. I simply can’t do more for you, than to urgently encourage to try
>     it out yourself, test it, see what it can do for you
>
> This time *toro C Library* (that is absolutely the same as the library 
> part of the latest
>
> CdePkg 
> https://github.com/KilianKegel/CdePkg/blob/master/CdeLib/CdeLib.mak#L15)
>
> for UEFI Shell will be discussed first, since “Tianocore Community” is 
> now aware of serious problems of edk2libc
>
> and probably ready to examine my solution,that lacks all of those issues.
>
> You, Maciej, can support *CdePkg/ toro C Library* by
>
>  1. testing *CdePkg*
>  2. giving feedback to the community
>  3. updating *CdePkg* to latest AAEON WhiskeyLake platform (that is on
>     my Desk for months but I simply don’t have time to get it running…)
>
> (MinnowBoard is deprecated now)
>
> The license issue /can not/ be discussed /before/ there is any serious 
> interest in *CdePkg* and *toro C Library*.
>
> But if you are seeking  for a free solution, that
>
>   * requires unknown additional working hours
>   * requires a couple of high motivated maintainers, specialized in
>     Standard C
>   * countless patches will spam your inbox folder for years
>   * additionally with unpredictable result
>
> please use  edk2libc, PDCLIB or adjust NewLib for your needs.
>
> >Unless those problems are solved, I simply cannot use it.
>
> Right, but you are invited to take a test drive!
>
> In the EDK2 Emulator. Debugging with the best Debugtool ever seen…
>
> Try to get SysPrep and Redfish running in the Emulator.
>
> Really, just do it!
>
> > How can I verify what was actually implemented inside?
>
> I will publish source code of *toro C Library* beginning 2022 and 
> discuss the design details along those files.
>
> But, did you check glibc’s fopen-source before using it?
>
> Have you ever seen 
> Microsoft/Borland/Symantec/ARM/IBM/Dinkumware/Greenhill/IAR … C 
> Libraries source code?
>
> Thanks,
>
> Kilian
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows
>
> *From: *Rabeda, Maciej <mailto:maciej.rabeda@linux.intel.com>
> *Sent: *Monday, November 22, 2021 05:31 PM
> *To: *devel@edk2.groups.io; KILIAN_KEGEL@OUTLOOK.COM
> *Cc: *Rebecca Cran <mailto:rebecca@nuviainc.com>; 
> tim.lewis@insyde.com; Mike Kinney <mailto:michael.d.kinney@intel.com>; 
> afish@apple.com; Leif Lindholm <mailto:leif@nuviainc.com>; Richardson, 
> Brian <mailto:brian.richardson@intel.com>
> *Subject: *Re: [edk2-devel] CdePkgBlog 2021-11-14
>
> Hi Kilian,
>
> From my point of view, the main problem with adoption of CdePkg to 
> EDK2 is that it relies on Torito C library.
>
>  1. Torito C library License
>     (https://github.com/KilianKegel/toro-C-Library/blob/master/LICENSE.md)
>     only allows for creating UEFI Shell applications.
>       * What about applications that do not rely on ShellPkg (example:
>         SysPrep application that might want to use Redfish, which
>         depends on C standard library)?
>       * What about drivers/libraries that rely on C standard library?
>       * How is that compatible with EDK2 BSD-2-Clause-Patent?
>  2. Torito C is pre-compiled.
>       * How can I verify what was actually implemented inside?
>         Industry would have to trust your tests, perform own set of
>         tests or/and disassemble it (doable, but unacceptable
>         effort-wise).
>
> Unless those problems are solved, I simply cannot use it.
>
> Thanks,
> Maciej
>
> On 14-Nov-21 20:51, Kilian Kegel wrote:
>
>     Hi All,
>
>     as announced last summer, I’d like to start a comprehensive
>     tutorial on
>
>     how to use Standard C / ANSI C in the UEFI environment and how to
>     design and implement
>
>     such a library for Shell and POST usage.
>
>     Since most parts of that comprehensive work are already done,
>
>     I will report, demonstrate and discuss implementation principles
>     and details on edk2.groups.io
>
>     as a kind of “blog” on a biweekly basis.
>
>     Please checkout my first CdePkgBlog
>     https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-11-14#cdepkgblog-2021-11-14
>
>     and enjoy the breathtaking build speed if compiler and linker are
>     used exclusively to create MY LEGACY TOOLBOX,
>
>     a handy set of one-trick-ponies that I have been using for about
>     25 years.
>
>     Have fun,
>
>     Kilian
>
> 

[-- Attachment #2.1: Type: text/html, Size: 15842 bytes --]

[-- Attachment #2.2: 3F1FECE7AF8044E584BF5D0CF3028E97.png --]
[-- Type: image/png, Size: 13937 bytes --]

Re: [edk2-devel] CdePkgBlog 2021-11-14

[Maciej Rabeda]

[-- Attachment #1: Type: text/plain, Size: 5725 bytes --]

Statement correction

On 30-Nov-21 11:09, Maciej Rabeda wrote:
> Hi Kilian,
>
> CdePkg *has not* been integrated into EDK2. It is simply in 
> edk2-staging, and that's a large difference.
> As for "satisfies all my needs" - it does not for the reasons I have 
> previously outlined.
>
> Reiterating: unless Torito C library *is released* as source code 
> under an EDK2-compatible license, I cannot use it. Period.
>
> Thanks,
> Maciej
>
> On 24-Nov-21 21:21, Kilian Kegel wrote:
>>
>> Hi Maciej,
>>
>> *CdePkg* is already integrated into EDK2 and satisfies all your needs 
>> for pre-/post-memory
>>
>> PEI, DXE, (SMM in latest releases only), BDS and UEFI Shell too.
>>
>> I have introduced *CdePkg* for POST usage 2 years ago without any 
>> interest of the “Tianocore Community”:
>>
>> https://edk2.groups.io/g/devel/message/51562?p=,,,20,0,0,0::Created,,CdePkg,20,2,0,65191785
>>
>>  1. Klick on the email link above
>>  2. Klick on the first link in that email, that goes to the
>>     edk2-staging\cdepkg folder
>>
>>  3. read the HOWTO:
>>     https://github.com/tianocore/edk2-staging/blob/CdePkg/README.md#howto
>>
>> *and go for emulation – that works perfectly.*
>>
>>  4. I simply can’t do more for you, than to urgently encourage to try
>>     it out yourself, test it, see what it can do for you
>>
>> This time *toro C Library* (that is absolutely the same as the 
>> library part of the latest
>>
>> CdePkg 
>> https://github.com/KilianKegel/CdePkg/blob/master/CdeLib/CdeLib.mak#L15)
>>
>> for UEFI Shell will be discussed first, since “Tianocore Community” 
>> is now aware of serious problems of edk2libc
>>
>> and probably ready to examine my solution,that lacks all of those issues.
>>
>> You, Maciej, can support *CdePkg/ toro C Library* by
>>
>>  1. testing *CdePkg*
>>  2. giving feedback to the community
>>  3. updating *CdePkg* to latest AAEON WhiskeyLake platform (that is
>>     on my Desk for months but I simply don’t have time to get it
>>     running…)
>>
>> (MinnowBoard is deprecated now)
>>
>> The license issue /can not/ be discussed /before/ there is any 
>> serious interest in *CdePkg* and *toro C Library*.
>>
>> But if you are seeking  for a free solution, that
>>
>>   * requires unknown additional working hours
>>   * requires a couple of high motivated maintainers, specialized in
>>     Standard C
>>   * countless patches will spam your inbox folder for years
>>   * additionally with unpredictable result
>>
>> please use  edk2libc, PDCLIB or adjust NewLib for your needs.
>>
>> >Unless those problems are solved, I simply cannot use it.
>>
>> Right, but you are invited to take a test drive!
>>
>> In the EDK2 Emulator. Debugging with the best Debugtool ever seen…
>>
>> Try to get SysPrep and Redfish running in the Emulator.
>>
>> Really, just do it!
>>
>> > How can I verify what was actually implemented inside?
>>
>> I will publish source code of *toro C Library* beginning 2022 and 
>> discuss the design details along those files.
>>
>> But, did you check glibc’s fopen-source before using it?
>>
>> Have you ever seen 
>> Microsoft/Borland/Symantec/ARM/IBM/Dinkumware/Greenhill/IAR … C 
>> Libraries source code?
>>
>> Thanks,
>>
>> Kilian
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
>> Windows
>>
>> *From: *Rabeda, Maciej <mailto:maciej.rabeda@linux.intel.com>
>> *Sent: *Monday, November 22, 2021 05:31 PM
>> *To: *devel@edk2.groups.io; KILIAN_KEGEL@OUTLOOK.COM
>> *Cc: *Rebecca Cran <mailto:rebecca@nuviainc.com>; 
>> tim.lewis@insyde.com; Mike Kinney 
>> <mailto:michael.d.kinney@intel.com>; afish@apple.com; Leif Lindholm 
>> <mailto:leif@nuviainc.com>; Richardson, Brian 
>> <mailto:brian.richardson@intel.com>
>> *Subject: *Re: [edk2-devel] CdePkgBlog 2021-11-14
>>
>> Hi Kilian,
>>
>> From my point of view, the main problem with adoption of CdePkg to 
>> EDK2 is that it relies on Torito C library.
>>
>>  1. Torito C library License
>>     (https://github.com/KilianKegel/toro-C-Library/blob/master/LICENSE.md)
>>     only allows for creating UEFI Shell applications.
>>       * What about applications that do not rely on ShellPkg
>>         (example: SysPrep application that might want to use Redfish,
>>         which depends on C standard library)?
>>       * What about drivers/libraries that rely on C standard library?
>>       * How is that compatible with EDK2 BSD-2-Clause-Patent?
>>  2. Torito C is pre-compiled.
>>       * How can I verify what was actually implemented inside?
>>         Industry would have to trust your tests, perform own set of
>>         tests or/and disassemble it (doable, but unacceptable
>>         effort-wise).
>>
>> Unless those problems are solved, I simply cannot use it.
>>
>> Thanks,
>> Maciej
>>
>> On 14-Nov-21 20:51, Kilian Kegel wrote:
>>
>>     Hi All,
>>
>>     as announced last summer, I’d like to start a comprehensive
>>     tutorial on
>>
>>     how to use Standard C / ANSI C in the UEFI environment and how to
>>     design and implement
>>
>>     such a library for Shell and POST usage.
>>
>>     Since most parts of that comprehensive work are already done,
>>
>>     I will report, demonstrate and discuss implementation principles
>>     and details on edk2.groups.io
>>
>>     as a kind of “blog” on a biweekly basis.
>>
>>     Please checkout my first CdePkgBlog
>>     https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-11-14#cdepkgblog-2021-11-14
>>
>>     and enjoy the breathtaking build speed if compiler and linker are
>>     used exclusively to create MY LEGACY TOOLBOX,
>>
>>     a handy set of one-trick-ponies that I have been using for about
>>     25 years.
>>
>>     Have fun,
>>
>>     Kilian
>>
>
> 

[-- Attachment #2.1: Type: text/html, Size: 16603 bytes --]

[-- Attachment #2.2: 3F1FECE7AF8044E584BF5D0CF3028E97.png --]
[-- Type: image/png, Size: 13937 bytes --]

CdePkgBlog 2021-12-12

[Kilian Kegel]

[-- Attachment #1.1.1: Type: text/plain, Size: 1334 bytes --]

Hi Maciej, hi all,

regrettably the announced CdePkgBlog for today is still under process and will be published
next Sunday.

And also the schedule for the other CdePkgBlogs has changed:
[cid:image001.png@01D7EF91.99009E90]

Here are some intermediate results:

  1.  Successfully updated https://github.com/tianocore/edk2-staging/tree/CdePkg   to edk2-stable202111   with latest Redfish-support
  2.  Redfish runs in Emulator-mode
  3.  “Just add your C standard library to the INF and – poof – everything works”: YES, of course, changes below is all you need

to get all of https://github.com/KilianKegel/toro-C-Library/blob/master/implemented.md#validation-status

[cid:image002.png@01D7EF92.57068DF0]
[cid:image003.png@01D7EF92.6F8DD9F0]


  1.  Command line parameters works for all Redfish-drivers in the Emulator
  2.  Successfully added all samples for all functions from <wchar.h> and <wctype.h> from

https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/WCHAR_H/wcharhfunctions/main.c and

https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/WCTYPE_H/wctypehfunctions/main.c
                to RestJsonStructureDxe-Component

  1.  Just need some days to finish a suitable review of the RedfishCrtLib design and implementation



Have fun,

Kilian



[-- Attachment #1.1.2: Type: text/html, Size: 6794 bytes --]

[-- Attachment #1.2: 08738CAF2A454B69BDE95E85A61AA01B.png --]
[-- Type: image/png, Size: 11693 bytes --]

[-- Attachment #1.3: 0FCAD214237640F4989EDEAF07E35AF9.png --]
[-- Type: image/png, Size: 103864 bytes --]

[-- Attachment #1.4: 41780803977C48A18277D7C01CB31809.png --]
[-- Type: image/png, Size: 114922 bytes --]

[-- Attachment #2: RedfishCredentialDxe.inf.diff.png --]
[-- Type: image/png, Size: 103864 bytes --]

[-- Attachment #3: RedfishCredentialDxe.c.diff.png --]
[-- Type: image/png, Size: 114922 bytes --]

CdePkgBlog 2021-12-19

[Kilian Kegel]

[-- Attachment #1.1: Type: text/plain, Size: 2688 bytes --]

Hi Maciej, hi all,

I didn’t get any feedback from you, what exactly you would like CdePkg
to do for Redfish.

So I chose to demonstrate all functions from wchar.h and wctype.h that are implemented in
toro C Library, but not available in your, Maciej’s,  preferred PDCLIB.

I provided also the source code of these functions for review.

Additionally I’d like to inform you, that my Standard C Library header files
for VS2022 for EDK2 usage are available in a EDK2 compatible license:
https://github.com/KilianKegel/CdePkg/tree/master/Include/VS2022

If you want to build the samples, please get the entire CdePkg from edk2-staging that also includes the blog,
https://github.com/tianocore/edk2-staging.git

If you just want to read the new blog:
https://github.com/tianocore/edk2-staging/tree/CdePkg/blogs/2021-12-19#cdepkgblog-2021-12-19

Have fun,
Kilian



From: Kilian Kegel<mailto:kilian_kegel@outlook.com>
Sent: Sunday, December 12, 2021 09:02 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Rabeda, Maciej<mailto:maciej.rabeda@linux.intel.com>; Rebecca Cran<mailto:rebecca@nuviainc.com>; tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>; Mike Kinney<mailto:michael.d.kinney@intel.com>; afish@apple.com<mailto:afish@apple.com>; Leif Lindholm<mailto:leif@nuviainc.com>
Subject: CdePkgBlog 2021-12-12

Hi Maciej, hi all,

regrettably the announced CdePkgBlog for today is still under process and will be published
next Sunday.

And also the schedule for the other CdePkgBlogs has changed:
[cid:image001.png@01D7F511.8AC27D50]

Here are some intermediate results:

  1.  Successfully updated https://github.com/tianocore/edk2-staging/tree/CdePkg   to edk2-stable202111   with latest Redfish-support
  2.  Redfish runs in Emulator-mode
  3.  “Just add your C standard library to the INF and – poof – everything works”: YES, of course, changes below is all you need

to get all of https://github.com/KilianKegel/toro-C-Library/blob/master/implemented.md#validation-status

[cid:image002.png@01D7F511.8AC27D50]
[cid:image003.png@01D7F511.8AC27D50]


  1.  Command line parameters works for all Redfish-drivers in the Emulator
  2.  Successfully added all samples for all functions from <wchar.h> and <wctype.h> from

https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/WCHAR_H/wcharhfunctions/main.c and

https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/WCTYPE_H/wctypehfunctions/main.c
                to RestJsonStructureDxe-Component

  1.  Just need some days to finish a suitable review of the RedfishCrtLib design and implementation



Have fun,

Kilian




[-- Attachment #1.2: Type: text/html, Size: 9824 bytes --]

[-- Attachment #2: 090DA288B9684CEE8DEBF340A362365D.png --]
[-- Type: image/png, Size: 11693 bytes --]

[-- Attachment #3: 7393E956CA344ED599EBF902CAD6E6A6.png --]
[-- Type: image/png, Size: 103864 bytes --]

[-- Attachment #4: B3C0BA2F84BC46B5A05002236F71CF3C.png --]
[-- Type: image/png, Size: 114922 bytes --]

CdePkgBlog 2022-01-16 -- Introduction of the ACPICA port to UEFI

[Kilian Kegel]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

Hi Andrew, hi Jordan, hi Maciej, hi all,

this task was suggested by @ajfish and @jljusten at tianocore / tianocore.github.io:
https://github.com/tianocore/tianocore.github.io/wiki/Tasks#port-acpi-ca-to-a-shell-application.

All in all it could be solved within a really small amount of time, with a small amount of changes and extensions  some months ago


  *   build Visual-ACPICA-for-UEFI-Shell: https://www.youtube.com/watch?v=POfSJQXi2aM
  *   run ACPIDUMP.efi and ASLCOMPILER.efi: https://www.youtube.com/watch?v=oA1GA95WrF0

My concept here was to choose the existing Microsoft VisualStudio package and
adjust it to run in the UEFI environment, by reimplementing missing Win32-API functions (amount of 8).
This could be done using the Microsoft-C-Library compatible toro-C-Library<https://github.com/KilianKegel/toro-C-Library#toro-c-library-formerly-known-as-torito-c-library>

Maybe that concept is also useable for porting “openSSH” to UEFI Shell: https://github.com/tianocore/tianocore.github.io/wiki/Tasks#port-openssh-as-a-shell-application

@Maciej Rabeda<mailto:maciej.rabeda@linux.intel.com>
The toro-C-Library source code is included in the project.
You can check what is inside, how it works internally and how I do believe a
C-Library for UEFI Shell/SMM/DXE/PEI should be constructed that guarantees
compatibility/portability+testability for POST drivers and UEFI/Windows Shell applications by design.

The “toro-C-Library” build engine is VisualStudio/msbuild.exe only. It takes 20 Seconds to get it done.
The older “torito-C-Library” build engine is EDK2Build. It takes 120 seconds to get it done, for the same result,
on the same build machine.

If you want to build the samples, please get the entire CdePkg from edk2-staging that also includes the blog,
https://github.com/tianocore/edk2-staging/tree/CdePkg

If you just want to read the new blog:
https://github.com/tianocore/edk2-staging/blob/CdePkg/blogs/2022-01-16/README.md#cdepkgblog-2022-01-16

Enjoy the breathtaking speed and elegance of VisualStudio

Have fun,
Kilian



[-- Attachment #2: Type: text/html, Size: 9491 bytes --]