From: "Michael D Kinney" <michael.d.kinney@intel.com>
To: Kilian Kegel <kilian_kegel@outlook.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: "Richardson, Brian" <brian.richardson@intel.com>
Subject: Re: [staging/branch]: CdePkg - C Development Environment Package
Date: Wed, 23 Oct 2019 22:06:05 +0000 [thread overview]
Message-ID: <E92EE9817A31E24EB0585FDF735412F5B9DF1171@ORSMSX113.amr.corp.intel.com> (raw)
In-Reply-To: <VI1PR0502MB3968B7310367A43D8341D263EB6B0@VI1PR0502MB3968.eurprd05.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 6029 bytes --]
Hi Kilian,
Thanks for the contribution. I have a couple quick comments.
* Some files do not have a file header at all. Please update these with a proper file header
* Some files have a BSD 2-Clause license. The preferred license for EDK II is BSD+Patent and we prefer SPDX identifiers. Will you be able to update to this license and header format?
* There are binaries (.lib) files in this branch. Source repos should not have binaries. The preferred locations for binaries are GitHub release pages for binaries build from a source tag or the edk2-non-osi repo.
* Can you please summarize the differences between the copies of the EmulatorPkg and Vlv2TbltDevicePkg in your branch and the versions of those packages in the edk2 and edk2-platforms repos? Do you need help from those package maintainers to resolve the differences?
Thanks,
Mike
From: Kilian Kegel <kilian_kegel@outlook.com>
Sent: Wednesday, October 23, 2019 1:02 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Richardson, Brian <brian.richardson@intel.com>
Subject: [staging/branch]: CdePkg - C Development Environment Package
Hi UEFI community,
I'd like to introduce the CdePkg to edk2-staging.
Some time ago I decided to write my own ANSI C Library for UEFI Shell and POST.
The UEFI Shell library ("Torito C Library") has been production-ready for more than one year.
The POST version of the library ("CdeLib") is not yet fully tested.
I will be demonstrating my verification procedure in the upcoming weeks on EDK2 STAGING https://github.com/tianocore/edk2-staging/tree/CdePkg
Currently there are 3 examples implemented:
1. argvc: https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/HOSTED_ENV/argcv/main.c#L57
argc/argv handling according to https://msdn.microsoft.com/en-us/library/a1y7w461.aspx
1. systeminterfacePEI: https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/SYSTEM_IF/systeminterfacePEI/main.c#L57
demonstration, how PeiServices and FileHandle are passed into main()
1. systeminterfaceDXE: https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/SYSTEM_IF/systeminterfaceDXE/main.c#L57
demonstration, how SystemTable and ImageHandle are passed into main()
Upcoming next demonstration will be the clock() function end of this week
The idea is to bring the ANSI C Library interface into POST drivers.
This will:
1. ease porting tasks
2. allow cross development
3. allow developers to focus on their aims, because they aren't forced to keep in mind a lot of additional info (e.g. RShiftU64)
4. provide all intrisics to allow the compiler to be a "C compiler"
(e.g. char buffer[256] = { 1 };)
What is CdePkg and Torito C Library?
* CdePkg and Torito C Library are a one man show / after work party, that is owned and written solely by myself
* CdePkg is a reference implementation only for Microsoft C compiler
* CdePkg is a feasibility study
* CdePkg is the successor of Torito C, based on the same source code
* CdePkg C Development Environment is similar to MdePkg Module Development Environment
but guarantees that the C compiler is always fully usable (all intrinsics available) and the C90/C95 standard library is always available
What are the design goals?
* to rewrite the whole thing from scratch, without using any public source code from GNU, BSD, Watcom
* completeness: full blown C90 + C95 support, as lowest common denominator
* tailored for UEFI: small code size, for UEFI-POST-driver uses a C-Library-Driver, that contains core/worker functions for realloc() == malloc() and free(),
entire printf()-family, entire scanf()-family.
UEFI-POST-driver just uses small wrapper functions to run the C-Library-Driver code.
* stable, exact, chipset independent TSC based clock() with CLOCKS_PER_SEC == 1000
* complete set of the Microsoft C-compiler intrinsic functions
* ROM-able! Runs with stack but w/o any static storage duration in .data segment, e.g. for rand(), strtok(), tmpfile()
This is required for early PEI before memory sizing, when PEI-images run directly out of flash
* Microsoft (bug) compatible (as far as possible)
* use original Microsoft header files for UEFI Shell Apps created in VS2019
* allow expensive debugging tasks of ANSI C .EFI applications in Visual Studio in its Windows NT counter part
* to save my lifetime writing a documentation https://github.com/tianocore/edk2-staging/tree/CdePkg/implemented.md#validation-status
* all the above in one single C-Library CdeLib.lib
CdePkg shall be adjusted to other compilers/tool chains too, once it is feature-complete and accepted by the UEFI community.
As long as it is for Microsoft VS2019 only.
CdePkg README.md is here: <https://github.com/MinnowWare/CdePkg#cdepkg> https://github.com/tianocore/edk2-staging/tree/CdePkg#cdepkg
CdePkg HOWTO is here: https://github.com/tianocore/edk2-staging/blob/CdePkg/README.md#howto
CdeValidationPkg README.md is here: https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/README.md<https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/README.md#cdevalidationpkg>
CdeValidationPkg HOWTO is here: https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/README.md<https://github.com/tianocore/edk2-staging/blob/CdePkg/CdeValidationPkg/README.md#howto>
HOWTO:
1. clone the edk2-staging repository
2. checkout CdePkg
3. run LAUNCH.BAT
4. run build -p EmulatorPkg\EmulatorPkg.dsc -t VS2015x86 -a IA32
5. run DBGEMU.BAT to start emulation (EmulatorPkg)
6. run build -a IA32 -a X64 -n 5 -t VS2015x86 -b DEBUG -p Vlv2TbltDevicePkg\PlatformPkgX64.dsc
7. update MinnowBoard with Build/Vlv2TbltDevicePkgX64\DEBUG_VS2015x86\FV\VLV.fd
Best regards,
Kilian Kegel
[-- Attachment #2: Type: text/html, Size: 70992 bytes --]
next prev parent reply other threads:[~2019-10-23 22:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 20:02 [staging/branch]: CdePkg - C Development Environment Package KILIAN_KEGEL
2019-10-23 22:06 ` Michael D Kinney [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-09-05 13:08 [Qemu-devel] [edk2-rfc] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF Laszlo Ersek
2019-09-05 15:49 ` [PATCH] q35: lpc: allow to lock down 128K RAM at default SMBASE address Igor Mammedov
2019-09-09 19:15 ` Laszlo Ersek
2019-09-10 15:58 ` Igor Mammedov
2019-09-11 17:30 ` Laszlo Ersek
2019-09-17 13:11 ` [edk2-devel] " Igor Mammedov
2019-09-17 14:38 ` [staging/branch]: CdePkg - C Development Environment Package Minnow Ware
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E92EE9817A31E24EB0585FDF735412F5B9DF1171@ORSMSX113.amr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox