From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (EUR03-DB5-obe.outbound.protection.outlook.com [40.92.71.101]) by mx.groups.io with SMTP id smtpd.web11.12323.1575995748730669493 for ; Tue, 10 Dec 2019 08:35:49 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: outlook.de, ip: 40.92.71.101, mailfrom: mhaeuser@outlook.de) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OEndmcbOxTN/OdCJM3MX4vdpI2esQE7yXBssDdYYHBCVJB/w96W2f0B8kEluMjavpGDqJSS3g9IffLdx0+jklvkbnL+zD5j2wyr9mYF1hLrqCIXDl2Jq4mJoLKva04GmiYH4q4kQTNDp/fNmv2AVRBtOmyf91JBlBFTjqjETydqBaA3qq4KRFmqAAs2CxNKF3hAJ09z+1U19DVXGIw9jn3dXKlWV2QLUbO+UHaUopEp1oMuOiLPvmBn//7IgEWN+06DafqtkNXuvDJ7NBdiOhFC5QpuBq4XBQhR1p7wvITkPjLEsy9oOTKF9l/2Nbh4cVsHltt49b5W384Si6Azk1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XVNJwq3WUm75YUH/QAmo0ma8v4oBrduGhJuhxx3KNMo=; b=LeNdoyhObE4vvlpdD9EfXL0PJUqXHY8a0V1MZEmQJCFnPxxBoeBvJeq3YzjVy4vQhJJydvwVIzvoSjz+6td3iEN1xDuBx9sPdYHvsDdcEhmXs2jG5tnZO4KPlnJdDMcc/JznU/RsvUUvoKHFCDsmIJNSVmydm17MXoaUzkMYHpIaehZzvKk+4uvJDsrNbwxrVDlC0q6cxNZs25drLstlKk+D7ns2HnvbZoIuIUoz7+m/v7Uut6Wzi8zXeNo16D45DFpywA4ikVZcaicFxrjI23uuXo0qHC4YHgK4MrMnfXRxYDSU0I+nzywCyjGsK9kjWbQ4lK4+c2+hFToQEgSUGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=outlook.de; dmarc=pass action=none header.from=outlook.de; dkim=pass header.d=outlook.de; arc=none Received: from AM5EUR03FT034.eop-EUR03.prod.protection.outlook.com (10.152.16.57) by AM5EUR03HT117.eop-EUR03.prod.protection.outlook.com (10.152.17.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Tue, 10 Dec 2019 16:35:40 +0000 Received: from AM6PR07MB5859.eurprd07.prod.outlook.com (10.152.16.57) by AM5EUR03FT034.mail.protection.outlook.com (10.152.16.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18 via Frontend Transport; Tue, 10 Dec 2019 16:35:40 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:D4976947C7556B0A372801454C2E71C40E53AA375575CA1F4891CC7654127C2C;UpperCasedChecksum:70B853E9DDAF3F75CC26EB10210385C5B73852CBCCC3C266930C15362776BFC8;SizeAsReceived:8026;Count:48 Received: from AM6PR07MB5859.eurprd07.prod.outlook.com ([fe80::bda2:d0ef:9b7f:b22a]) by AM6PR07MB5859.eurprd07.prod.outlook.com ([fe80::bda2:d0ef:9b7f:b22a%3]) with mapi id 15.20.2538.012; Tue, 10 Dec 2019 16:35:40 +0000 Subject: Re: [staging/branch]: CdePkg - some more details To: Kilian Kegel , "devel@edk2.groups.io" CC: "Kinney, Michael D" , "Richardson, Brian" References: From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Message-ID: Date: Tue, 10 Dec 2019 17:35:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 In-Reply-To: X-ClientProxiedBy: FR2P281CA0016.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::26) To AM6PR07MB5859.eurprd07.prod.outlook.com (2603:10a6:20b:37::21) Return-Path: mhaeuser@outlook.de X-Microsoft-Original-Message-ID: MIME-Version: 1.0 Received: from [192.168.1.234] (95.88.197.93) by FR2P281CA0016.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=) via Frontend Transport; Tue, 10 Dec 2019 16:35:39 +0000 X-Microsoft-Original-Message-ID: X-TMN: [1/7GQjBsO69kh2eHX6Ggv7KSOKJ4zKjL] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: fc6f07ed-dc4f-4e1e-26dc-08d77d8efde3 X-MS-Exchange-SLBlob-MailProps: =?us-ascii?Q?7FNIAzWC7Tonmsx6ow3XyJ7wdgtWq5o6WWIO4q5E+Uim5n59CpSGQu+LkOcx?= =?us-ascii?Q?IRdnRd1PVAreuC5JXTiez41se7ZcjESuz8Dv6X5mQhc6L5neVbECpgzbpgjf?= =?us-ascii?Q?gMFa8pvSayk5AWThvkNvxy93bEDcGsaYnFO5lVPgt7jtvDdH23KLz4WmBqFQ?= =?us-ascii?Q?oNWS0jkI0NceQBvaMVksW5B4/C1d4Ck/mBdPmDsx6YxIa4AGyAdHBs2yx77+?= =?us-ascii?Q?7VmjjaeYu4pCj5UcvckT3O/mNRfS0PbTtoJ9BrMHngOTPwl1+qRsVUFUvkau?= =?us-ascii?Q?Zmdycy7aaRzOnV14EDFl8ghs5L77T1Nztxp/T0aG/qWvwaNMG7XBPKG+Q1ne?= =?us-ascii?Q?4aS0aYacfvG+v0SAyUsprkfIRPDmJw5RK4I8OMAXre4VPXrHBKrpXHAlBibb?= =?us-ascii?Q?DAfyg6uBaTtOiWXqwl2/AjNsW+ClNpiGdQc2OM4TNTasFlX/60/Tf8hJCCUD?= =?us-ascii?Q?ol+xNt5fhkyUreia6lkgp/3ZEqxSwVthVMdYKBFxS+sPadmuf3HzGdXdmI2v?= =?us-ascii?Q?tsaiq1j+B/q27B+3csCKahFV09taqoTC0Dk3TfrMZPXpOAxazCFkm/VKX+dE?= =?us-ascii?Q?Pvh0vEHCuv0LlaIujJbe7uM3FPNaRT/+5g+yDd8fu+QCz0WJSmjZSR5zVecO?= =?us-ascii?Q?yj1gD7bxSREuh73AUkdJNDPZizqOQkSWYdMY/iQrqcCu0AZzkjD1a2qYoPtQ?= =?us-ascii?Q?WDOyIS8aUMhHsCyxWaf5IffKtWCmZclh01EORNORwJu+RvGE8UVrUHn1o3G1?= =?us-ascii?Q?9+omTv/qoancV0ZGu3JsvfpEVEnJ80LbGLS4klXdriivqXwPvi6XCEjKYirN?= =?us-ascii?Q?rztICziqk9bQh5LieEtaDzz7VgnN7eAGFXav8OjDX8WV+1/L3AH6FHf1olCy?= =?us-ascii?Q?TYc/04AIhr/K+HCuWrEHRK0Y0mL2N8L9Rw/+p13PiQI36Dz8Ce+la7IWa4bc?= =?us-ascii?Q?yzGPc/vDTory4uOUS6G/G5ymgyofXTWmAmPU5ZsviQuiZvc2qnMOEXVL6sfN?= =?us-ascii?Q?q81bNheWE2+nkXEVNFi5/RECU0YAULQ2XcnObKRSGsrBEdcavAQp7GWJ7d/9?= =?us-ascii?Q?vaNaQ2+zUB2efgxk9Ag=3D?= X-MS-TrafficTypeDiagnostic: AM5EUR03HT117: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ta8dOsrf5lB/MEnRpaSKeG+T7eL6kG0GBbhuuAtPEUeW/FuwJwlHaEGNKxE8619N1goGVjwEeWmZCNvkGrwsctJtesx0SxwUjAN+sDd3NphuG4s+dHDI9yUlN7XuFgAIKYbzHjYDaK9nh5bnRP3dJPj/Fo7SwvRTyl9HIDvloy69LlRa7es9KhsIuNGJVg4/j3T95rB2NaoVlinSPqCwctTWtnLN//Z8nOWq7Q3pnaU= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc6f07ed-dc4f-4e1e-26dc-08d77d8efde3 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Dec 2019 16:35:40.5588 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT117 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Good day Kilian, Comments are inline. Thank you very much for your very comprehensive explainations! Please do not understand my sceptical tone as if I didn't want this=20 project to succeed, my concerns are a lot more organisation-centered=20 than on the work on the library itself. I wish you the best of luck with your project! Best regards, Marvin Am 10.12.2019 um 08:23 schrieb Kilian Kegel: > Resend to >=20 > Hi Marvin, hi UEFI community, >=20 > sorry for being late with my reply, >=20 >> As far as I understood it, it aims to provide an actual full C standard= library implementation >=20 > Yes, full with known limitations regarding file access, console access= =20 > and related requirements >=20 > (e.g. all *f...()* functions or *system(=93echo Hello world=94) *won=92t= be=20 > run in POST) Got it, thanks! >=20 > Here is a list of 110 ANSI C functions that already run in PEI, DXE=20 > using CdePkg and UEFI Shell using Torito C Library: >=20 > https://github.com/tianocore/edk2-staging/blob/CdePkg/implemented.md#val= idation-status >=20 >> Is this planned to land in edk2 >=20 > This would be my proposal for future UEFI based firmware BIOS products= =20 > like modernFW. >=20 > As UEFI implements a filesystem =93FAT32=94, >=20 > I propose to implement additionally a =93C=94 interface to modernFW to: >=20 > * make it trustable for security, finance, military and government > applications/platforms/products I do not get your point here - a standard compliant interface itself is=20 supposed to make it more trustable? I think I misunderstand you here. > * demystifying UEFI BIOS firmware by providing a =93known=94 API > > that shall be extended to secure/bounds checking interface of C11 e.g.= =20 > snprintf*_s*() >=20 > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Annex K >=20 > * improve maintainability by using =93standard=94 functions known to t= he > compiler and to static code analysis tools >=20 > (that warns at=A0 parameter mismatch e.g. on sprintf() at buildtime) >=20 > * allow validation by C validation suites CVS from third party vendors > * make it usable and understandable for =93normal=94 IT professionals = and > application developers,=20 The points about existing validation suites, static analysis support and= =20 such are all good. >=20 > writing shell apps and OPTION ROMs; developers are forced to understand= =20 > a lot of the EDK buildprocess >=20 > and EDK libraries before they can write a simple flash tool=85 (at=20 > companies like Broadcom, Realtek, LSI, Emulex, >=20 > Infineon, PC manufacturers=85) >=20 >> and if so, in what ways will one be encouraged to use it? >=20 > EDK-STAGING is the place on tianocore.org where new features that are=20 > not ready for product >=20 > integration can be checked in for evaluation by the EDK II community=20 > prior to >=20 > adding to the edk2 trunk=85 >=20 > https://github.com/tianocore/edk2-staging Thank you, but I am aware of this. I am more interested in the future=20 mainline usage, i.e. the final goal of this initiative. >=20 >> Usually it's considered best practice to keep the code quantity in low = levels to a minimum, >=20 > this might be true for small microcontrollers. >=20 > On x86 architecture UEFI runs on 64 Bit processors that start in 32 Bit= =20 > mode and use CAR Cash As RAM to get PEI >=20 > in C running before memory detection. Usually those platforms=A0 have a= =20 > multi megabyte cache available for CAR. This point was not about code size or resource consumption, but that is=20 also a concern. When making a point about such, you cannot take the best= =20 case (x86-based products which are optimised for performance and=20 support) but must take the worst case (e.g. I have seen edk2 has been=20 ported to Raspberry devices and other embedded systems), where the=20 resources are far more limited. For CDE itself, I'm not worrying about=20 the resource consumption though, at most so when combining it with edk2. The actual point is about validation. We should not strive for a=20 feature-rich framework to get everyone happy with the interface, but for= =20 a rock-solid fundament that is easy to verify and validate. 110 ANSI C=20 functions which overlap with edk2 functions mean 220 functions to=20 validate and maintain, and this, in my opinion, is disastrous. I do not=20 know about how well C standard functions work out in firmware=20 implementations, but if they work out as well as edk2-specific stuff,=20 I'd strongly suggest and favour deprecating edk2 concepts in favour of=20 ANSI C step by step. I have also seen efforts to allow Rust support for edk2. *Please* engage= =20 with the different people proposing different modernisations for the=20 project to not end up with a suboptimal middle ground, a lot of scrapped= =20 work, or, at worst, many alternatives. Supporting traditional edk2, CDE=20 *and* Rust at once sounds absolutely horrible to me. Currently, it=20 sounds a bit chaotic to me where edk2 is heading. This does make me wonder, why was edk2 designed with this set of=20 proprietary functions and types, manifested in even the specification,=20 in the first place? Is there a practical point regarding ANSI C design=20 or just the compiler situation when the original EDK was written? If=20 former, that should surely be considered in the CDE design. >=20 > For those machines ANSI C shall be considered as the lowest common=20 > denominatorrequired for string processing / , >=20 > character handling / , time and date serviceing=20 > , string to number conversion and vice versa , >=20 > memory allocation,=A0 global jumps and exit() services =85 >=20 > Most of that functionality is already provided in UEFI in ANSI and=20 > UNICODE representation each as a >=20 > proprietary interface and=A0 lacks compatibility with ANSI C. I'm all for moving to ANSI C for all *existing* concepts. A full C=20 standard library consists of a lot of concepts that we probably do not=20 want in firmware, including but not limited to advanced (or any really)=20 floating point support, math operations, signals, advanced=20 multithreading, advanced file and console I/O, advanced environment APIs= =20 (e.g. locale, time). I know a bunch of those are optional and were=20 probably not considered in the first place, but I wanted to stress to=20 keep it as simple as possible - and if that means to deviate or just=20 ignore parts of the standard (library), I think that should be done. But just for the basic stuff, I would really appreciate ANSI C support.=20 This is for basic APIs (malloc, str*, etc) and especially types. Integer= =20 Promotion is an essential aspect of C, I don't know how one can just=20 banish that type from their vocabulary like that. This can make things=20 like the print functions a bit inconvenient. I do not see how UEFI's=20 types make any sense over standard fixed-width types either. Did any of the edk2 designers (or Stewards? Sorry, I don't understand=20 who is in charge of what very well) comment on this kind of stuff before? >=20 >> and I do not think even most kernel spaces implement a *full* C standar= d library for this reason. >=20 > If you consider BIOS flash space requirements, it is delightfully small,= = =20 > much smaller than you expect, and >=20 > probably smaller than the current implementation. >=20 > Because it is consistently divided into wrapper library and worker drive= r. >=20 > The =93big=94 worker code is present once per PEI/DXE/SMM phase only. >=20 > The code from the wrapper library is linked into the drivers binary only= = =20 > on demand. >=20 > This is the =93traditional=94 library concept. >=20 > The full functionality (CdeServices) needed for=20 > malloc()/free()/realloc(), entire=A0 printf()-family (narrow and wide), >=20 > entire=A0 scanf()-family (narrow and wide), most=A0 string processing=20 > functions (narrow and wide) needs >=20 > much less than 20KB (DXE) / 15KB (PEI) and could also serve as a=20 > C-Library-driver for UEFI Shell programs (DXE driver). >=20 > https://github.com/KilianKegel/CdeBinPkg/blob/master/CdeServices/CdeServ= icesDxe64.efi >=20 > https://github.com/KilianKegel/CdeBinPkg/blob/master/CdeServices/CdeServ= icesPei32.efi >=20 > Let=92s have a look into some ANSI C functions that interact with the=20 > *CdeServices* driver: >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/s= tdio_h/Vsscanf.c#L50 >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/s= tdio_h/Printf.c#L34 >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/s= tdlib_h/Realloc.c#L21 >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/s= tdlib_h/strtol.c#L58 >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/s= tring_h/StrTok.c#L25 >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/t= ime_h/clock.c#L37 >=20 > On function entrance they all fetch the application interface, that=20 > contains the pointer to >=20 > the =93*CdeServices*=94 protocol: >=20 > ** >=20 > *CDE_APP_IF *pCdeAppIf =3D _GetCdeAppIf();* >=20 > ** >=20 > That, itself is allocated once during drivers runthrough=20 > driverentrypoint/CRT0(): >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/OSInterfa= ce/OS_DXE/osifUefiDxeEntryPoint.c#L125 >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/OSInterfa= ce/OS_PEI/osifUefiPeiEntryPoint.c#L97 >=20 > A lot of functions defined in the ANSI C library don=92t need any space= =20 > optimizing, because they are that small by nature: >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/c= type_h/islower.c#L38 >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/c= type_h/isalpha.c#L39 >=20 > https://github.com/KilianKegel/CdeBinPkgSrc/blob/master/CdeLib/Library/s= tring_h/StrLen.c#L16 >=20 > That is true for DXE/(SMM) and PEI. >=20 >>and is there a chance the rest of edk2 is (very slowly) transfered to a = standard C >=20 > That=B4d be my idea, but it depends on the acceptance. That was my biggest concern, really. I think this project can do a lot=20 of damage if it is not fully accepted but only provided as a mere=20 alternative by choice. It makes review (quantity) and understanding the=20 control flow (two separate API designs) harder, overcomplicates the=20 codebase (e.g. folder layout) and may lead to multiple functions per=20 purpose (MDE *and* CDE) per module, which will degrade performance=20 (binary size -> code cache, load time, etc). But I also think it can do a lot of good if it is accepted and executed=20 well, so I hope this gains some actual traction. So far I only have seen= =20 you posting about it, and that worries me. Are there disucussions going=20 on in the background? >=20 > I will provide a demonstration on how to convert an existing MdePkg UEFI= = =20 > driver to >=20 > CdePkg extention soon. >=20 >> Or will it "just" be a handy set of libraries for porting purposes? >=20 > I am talking about one single C library CdeLib (as each normal=A0 C=20 > library or LIBC is always >=20 > provided as one single library file). >=20 > CdePkg does not need multiple libraries. There is one driver and one=20 > library per POST phase Sorry, this was unclear, I did not mean it in a edk2 module sense, but=20 the separation into groups (stdio, stddef, stdlib, ...). The actual=20 point was the "just", as in an alternative, as discussed above. >=20 > only (the command line driver is a temporary addition). >=20 > All=A0 built out of the same source code. >=20 > EDK2 is only the firmware fundament for final PC products (server,=20 > desktop, notebook, industry PC, Tablet) >=20 > e.g.=20 > https://www.fujitsu.com/global/products/computing/peripheral/mainboards/ >=20 > The final products needs lots of improvements and extensions to=20 > withstand the >=20 > market requirements and the competitors offerings and to match the=20 > customer demands. >=20 > PC products for business applications implements many additional > features e.g. >=20 > * LAN wakeup for different NICs Marvell, BroadCom, Realtek, Intel=85 > * keyboard power button wake out of S5 > * LAN Boot > * USB Port Protection/Disable for security purpose > * authentification via CardReader in POST > * power fail recovery including setup wake resources after power fail > * console redirection for AMT or DASH > * hard disk security around security freeze lock > * boot device selection by boot menu / hot key > * HDD SMART > * HSTI Hardware Security Test Interface > * TPM > * OA OEM activation > * (Server runtime) error logging > * (remote) BIOS configuration / setup settings, > * graphical setup > * Server RAS features > * IPMI support > * NVRAM backup > * LVDS display support for industrial applications > * brightness slider support > * password protection for boot/ HDD/ setup, > * fan control > * industry requirements:=20 >=20 > forced preference of =93signed=94 USB flash/CDROM/HDD drives in >=20 > the BIOS boot order for maintenance and service >=20 > * runtime counter > * exchangeable customer logo >=20 > (this is a selection of features I worked on the past 10 years doing=20 > UEFI BIOS projects). >=20 >> Especially in latter case, this, to me intuitively, sounds like a maint= enance and reviewing nightmare >=20 > Absolutely not, because it is easy to compare each function=B4s behavior= = =20 > against its corresponding >=20 > Microsoft LIBCMT.LIB pendant, once you have started the=20 > */CdeValidationPkg.sln /*Visual Studio solution: >=20 > cid:image004.png@01D5AEB1.24B7B000 >=20 > Each sample provided in the CdeValidationPkg can be translated for and= =20 > run on Windows Console, UEFI Shell, DXE and PEI >=20 > (except the SystemInterfaceDxe/PEI projects) >=20 > All implemented ANSI C functions are already tested and validated=20 > comprehensively that way. Well, yes, but this seems to be basically unit testing, I meant in a=20 sense of formal review. The problem is not the characteristics of your=20 project, but the fact that it duplicates existing concepts. If you=20 believe in the advantages of this approach, I hope you aim to deprecate=20 existing edk2 pendants step by step. >=20 > Therefore I am pretty sure, you=B4ll have to try hard to find one single= = =20 > bug beside >=20 > https://github.com/KilianKegel/torito-C-Library#known-bugs >=20 > if any=85 >=20 > To get the validation modules=A0 running in POST you have to use the=20 > traditional EDK2 build process: >=20 > 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*| >=20 >>curious about its purpose and future >=20 > with a =93C=94 interface provided as CdeServices it would: >=20 > 1. allow Shell apps / DXE/SMM/PEI driver to share the same sourcecode > (beside API specific parts) > 2. Share or reuse source code with open source > 3. allow use of automatically generated source code by > syntactical/lexical analysis tools (lex/yacc) > 4. ease programming tasks that deal with text processing (e.g. device > path, setup strings), time and date handling=85 >=20 > because ANSI C is standardized >=20 > 5. allow prototyping as a UEFI Shell application or as a Windows > Console application to=A0 be debugged with >=20 > superb Windows debug tools >=20 > 6. dispense the need of reading the source code to get an idea about > exact behavior of a particular function as >=20 > (https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BasePrintL= ib/PrintLib.c#L26 >=20 > Thanks for your curiosity and best regards, >=20 > Kilian >=20 >=20 >=20