From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (EUR04-HE1-obe.outbound.protection.outlook.com [40.92.73.105]) by mx.groups.io with SMTP id smtpd.web10.4691.1628136887850202544 for ; Wed, 04 Aug 2021 21:14:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@outlook.com header.s=selector1 header.b=OA0444LC; spf=pass (domain: outlook.com, ip: 40.92.73.105, mailfrom: kilian_kegel@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iYMAqNgK9oqIBjqWaa/k+rk/csOz9Py0DMEgw1xTbGf1eCOnstnY9mT4SR/W4xvEuzScSPPRXf3BD1hvSZSjwmizNFUK1X5BD7KmHbb6g7FQQoBWbekEIVLKI38An5rF98OuBeS7LwHitJ/vJaJ23rd/oH4RPKfOI6jvS9GGKZUh5J32lb9DdN9TDfU1d87gUqZ7JSuHgQbkB2o54VmriNy7hvx0sESw7gljZqJA3S3YxHE9/NRqaSKR6p0EgEF24mnFjbK+g6VT25uxpsGWyw/DUDTD6nj8ynpLwN9z0CS0LIqIiQGVCmqrzuWGLNawduvoTinXBttQf5Axv6ka4A== 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=pQNc5yzw5XoWmOwn3y+/ELwQzVC98DLEkD/XtL5QoAk=; b=IyFRrikgnzOEMhc1F3Bg++jYMEt2K2FI0bBoEjndUt8dfk1pI4O/G39LL8T0Pr5km4VxCWv5F8/PRxem72135wl4VnzKPM4b75qNPorAmAVW4tzo6hdMQw/YljDG4+SFMiGmtxBP79t3bZS13+oforUD8622kZn1vYnh28m5bI9hF2IboycSxbWxmVNfgWcWLOm8qmdJxOIDNRNk+2FCJjA+zq15URYOR89sbWyCqle7Jv1pFR5p/YttjDjMPp2+0CxUbcir931Va0k2vYiinll/C0xHQw0jFz4pYm8RhBoZJiBcI7skWPhdKKKUM65XWZwZJ7PMoN6eoghU50Fplw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pQNc5yzw5XoWmOwn3y+/ELwQzVC98DLEkD/XtL5QoAk=; b=OA0444LCs1vXTbf5YpcvA3AWsPemaMcEj91rF3w3iVU++4MPbVigyaL0OROGJXbDXm0/0dB/WModcB371wlHB9fv/jPB4lgsXnYcmBgxR/SIBzyNdUWRXpTdMuqPKSLztffdJ9M2feNYE9Pe0W6n9M9tulheB6ry0fbR8zQJmdLjg+Uf3zZHGoHyCktEm7MnNyEnPpG3pEOizAszg2Zes27P2LmDDMFt58ibWGBm8KNvWkj7CMrgg6ujw+GubfD2UyIxNm2Gi8ld1wOV91x8zgts5VI8L2STVp7043Dd2JnuN3pXSOrSTsdJA7+Y57hhI8T4l3JV4YgL5EXEqeIAZA== Received: from VI1EUR04FT043.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0e::40) by VI1EUR04HT171.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0e::120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18; Thu, 5 Aug 2021 04:14:43 +0000 Received: from AM8P190MB0945.EURP190.PROD.OUTLOOK.COM (2a01:111:e400:7e0e::42) by VI1EUR04FT043.mail.protection.outlook.com (2a01:111:e400:7e0e::299) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16 via Frontend Transport; Thu, 5 Aug 2021 04:14:43 +0000 Received: from AM8P190MB0945.EURP190.PROD.OUTLOOK.COM ([fe80::11a:1fc3:8a96:a2fe]) by AM8P190MB0945.EURP190.PROD.OUTLOOK.COM ([fe80::11a:1fc3:8a96:a2fe%8]) with mapi id 15.20.4394.016; Thu, 5 Aug 2021 04:14:43 +0000 From: "Kilian Kegel" To: "devel@edk2.groups.io" , "afish@apple.com" , Leif Lindholm CC: Rebecca Cran , "tim.lewis@insyde.com" , "maciej.rabeda@linux.intel.com" , Mike Kinney Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging Thread-Topic: [edk2-devel] "StdLibPkg" branch on edk2-staging Thread-Index: AQHXgv7qAR9uGbr9SU+yhcSwv8ebZKtYhhmAgAByzwCAAAU5AIAKPI2AgAEVNwCAAACCeg== Date: Thu, 5 Aug 2021 04:14:43 +0000 Message-ID: References: <0fb201d783ff$75096c90$5f1c45b0$@insyde.com> <20210804110321.ru56hfsyrfrviuwk@leviathan>,<10E41009-D3D6-4166-8843-1D04ECA6CC59@apple.com> In-Reply-To: <10E41009-D3D6-4166-8843-1D04ECA6CC59@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:10F4D64737695AC6377C6A89BB2422330957F567E8E29309B0315C3EA8AFD406;UpperCasedChecksum:EF30D59108EEF9C7AE864AD41CB7CF212F31D9D0EF3B743C90444AC2694426C5;SizeAsReceived:7388;Count:44 x-tmn: [E4+noztKkhvOqe7ICXiDB19UScXT5RPEPxOtyRlmoJ+GCvoqmgt3fu+vLe91ZG1e] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 986be476-b7fa-4500-ea1c-08d957c78d6a x-ms-traffictypediagnostic: VI1EUR04HT171: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Pvo2VaFdORFBaMzkBxYwqgaiasg6OFUc4ZrDqARjOSp2zicJRDYAXQs4bnIaPGIQ/G6Cx3VKkCs0j9ZlqP19QhgNRnUU7pTIk/XHq82f12KgvmAwX2AnNoLUWmZwrs0mHv4nk3TtIAt0U7Bhhrahz8MqoDsgfYd5yerE2Xrn3ZUJRG4p8b92Au9DNm6c2FXb2R7yXc9JvghK2t0nFOw4dxVW0ZsU9LZKDKpW3PsTQHTCONFQI8DsWM2Sxa0lYMmEmZLQWiJxBbPLGJ+bFconhC5t1ITV3IQ+92QgzenCAezfgo8dpHitP9VFDvLpaQKBDpSFZpp93zvitNYCdNyI/hMypL1Hr5hMeESdkQ860FywAKKsLvLHOegzvUANHTBfW0dTQUKcKXFDByi3k3iWXGmHO9HTJX81+C1VrVb//4ji61IjWoKLqIm4KFy9fJhFh/F2ZC7PKjrBPGX/tboMWkjrPE3yExwbrB3X0/zxUx8= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: Jv0NO8zYu3mcSPkZa+ZCcDeLnAEvWLTchSwA+W8v0XuMcPL0tGHDgzZSXVQMfZAfRrTteQNo/kofSkmW1nVcobykoS2wrhDcuj1Swd9C1vwA9cnCMa8m4a9ZkopZghUIj6fddZxIJJ1uL62ZncR1BE7UDMkpuHUhnn3279R8OSkzrhUsvyGtERHO77QG5ul14sdDExD5A0gK0Rd0A/Mrhw== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: VI1EUR04FT043.eop-eur04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 986be476-b7fa-4500-ea1c-08d957c78d6a X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2021 04:14:43.1372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR04HT171 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM8P190MB0945216D70EA74C5B5D36235EBF29AM8P190MB0945EURP_" --_000_AM8P190MB0945216D70EA74C5B5D36235EBF29AM8P190MB0945EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I plan to come back with the https://github.com/tianocore/edk2-staging/tre= e/CdePkg end of this year and to unroll the source code of fundamental parts of my C Library and dis= cuss that along the 30. anniversary of =93The C Book=94 https://publications.gbdirect.co.u= k/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 platfor= m 2. how to test and verify the compatibility of a Standard C Library imp= lementation, since =93CI=93 won=92t 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 f= unctions for PEI and DXE Note: If UEFI is going to provide Standard-C-Functions for all drivers, yo= u will have soon e.g. =93sprintf()=94 in all drivers. The amount of code for a proper sprintf() + scanf() + wsca= nf() + strtok() + wcstok() + malloc() =85 implementation that is not tailored for embedded FW, will overrun the BIOS FLASH space in= stantly. 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 =93DEBUG=94 traces by CdePkg-traces that allows usage of predefined DEBUG-messages to run in a CdePkg-based dr= iver. 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=3D,,,20,0,0,0::Created,,Cde= Pkg,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 =85 But https://github.com/KilianKegel/CdePkg.git driver set and sample set ru= ns instantly on the latest BIOS of a commercial vendor on a Intel IOTG TGL-H (Tiger Lak= e H) board using the Microsoft build environment. @Tim: I=92d really appreciate if CdePkg could hold additionally Insyde BIO= S support. Regrettably I do not have access to Insyde source code. @Maciej I can not see any =93wide=94 functions here. https://github.com/DevSolar/p= dclib from WCHAR.H or WCTYPE.H. That is a serious limitation in the UEFI environ= ment. 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 Sent: Thursday, August 5, 2021 05:35 AM To: edk2-devel-groups-io; Leif Lindholm Cc: Rebecca Cran; tim.lewis@insyde.com; maciej.rabeda@linux.intel.com; Mike Kinney Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-staging I=92d guess I=92d also ask the why not NewLib? Especially since Red Hat he= lps out with edk2=85. Thanks, Andrew Fish > On Aug 4, 2021, at 4:03 AM, Leif Lindholm 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-li= bc >> work against current edk2 master. >> >> Tianocore stewards: do we need new or additional maintainers for edk2-l= ibc, >> 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 >> M: Jaben Carsey >> >> >> -- >> 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 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 ? >>> >>> > > > > > --_000_AM8P190MB0945216D70EA74C5B5D36235EBF29AM8P190MB0945EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

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 =93The C Book=94 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 calibrati= on - platform,

processor  and chipset independent for = x86 UEFI platforms

  1. how to arrange space optimization for UEFI FW as an embedded platfor= m
  2. how to test and verify the compatibility of a Standa= rd C Library implementation,

since =93CI=93 won=92t help at all in this r= egards

  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 ma= nagement functions for PEI and DXE

 

Note: If UEFI is going to provide Standard-C-Functi= ons for all drivers, you will have soon e.g. =93sprintf()=94

in all drivers. The amount of code for a proper spr= intf() + scanf() + wscanf() + strtok() + wcstok() + malloc() =85 implementa= tion

that is not tailored for embedded FW, will overrun = the BIOS FLASH space instantly.

I consider commercial BIOS implementations that run= s 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 =93DEBUG=94 traces by CdePkg-traces<= o:p>

that allows usage of predefined DEBUG-messag= es 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 driv= ers 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 alr= eady available for 2 years:

https://edk2.groups.io/g/devel/message/51562?p=3D,,,20,0,0,0::Create= d,,CdePkg,20,2,0,65191785

 

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

 

I need to implement some non-standard / Micr= osoft 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 =85

 

But https://github.com/KilianKegel/CdePkg.git driver set and sample = set runs instantly

on the latest BIOS of a commercial vendor on a Inte= l IOTG TGL-H (Tiger Lake H) board using the Microsoft

build environment.

 

@Tim: I=92d 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 =93wide=94 functions here. https://github.com/DevSolar/pdclib

from WCHAR.H or WCTYPE.H. That is a serious limitat= ion in the UEFI environment.

 

To create UEFI-Shell programs for Personal Computer= s this link can be used.

https://github.com/Kilian= Kegel/Visual-ANSI-C-for-UEFI-Shell#visual-ansi-c-for-uefi-shell

 

Best regards,

Kilian

 

From: Andrew Fish via groups.io Sent: Thursday, August 5, 2021 05:35 AM
To: edk2-devel-groups-io; Leif Lindholm
Cc: Rebecca Cran; tim.lewis@insyde.com; maciej.rabeda@linux.intel.com; Mike Kinney
Subject: Re: [edk2-devel] "StdLibPkg" branch on edk2-stag= ing

 

I=92d guess I=92d al= so ask the why not NewLib? Especially since Red Hat helps out with edk2=85.=

Thanks,

Andrew Fish

> On Aug 4, 2021, at 4:03 AM, Leif Lindholm <leif@nuviainc.com> w= rote:
>
> 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<= br> > security fixes.
>
> I personally have no enthusiasm for the topic, but if there existed:<= br> > - 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 e= dk2-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 htt= ps://github.com/andreiw/UefiToolsPkg) but never any
>> help to upstream these fixes, including making sure that many Lin= ux
>> 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 allo= ws
>>> support under PEI, DXE, etc.
>>>
>>> Tim
>>>
>>> -----Original Message-----
>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Be= half 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 edk= 2-staging
>>>
>>> Are you aware of the edk2-libc project at https://github.com/tianocore/edk2-libc ?
>>>
>>>
>
>
>
>
>





 

--_000_AM8P190MB0945216D70EA74C5B5D36235EBF29AM8P190MB0945EURP_--