From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mx.groups.io with SMTP id smtpd.web10.144.1637598678338208622 for ; Mon, 22 Nov 2021 08:31:18 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: linux.intel.com, ip: 134.134.136.100, mailfrom: maciej.rabeda@linux.intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10176"; a="298233064" X-IronPort-AV: E=Sophos;i="5.87,255,1631602800"; d="scan'208,217";a="298233064" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2021 08:31:17 -0800 X-IronPort-AV: E=Sophos;i="5.87,255,1631602800"; d="scan'208,217";a="456341720" Received: from mrabeda-mobl.ger.corp.intel.com (HELO [10.102.8.21]) ([10.102.8.21]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2021 08:31:15 -0800 Message-ID: <9d11fe9d-b712-0c43-78e4-ff185112336b@linux.intel.com> Date: Mon, 22 Nov 2021 17:31:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [edk2-devel] CdePkgBlog 2021-11-14 To: devel@edk2.groups.io, KILIAN_KEGEL@OUTLOOK.COM Cc: Rebecca Cran , "tim.lewis@insyde.com" , Mike Kinney , "afish@apple.com" , Leif Lindholm , "Richardson, Brian" References: <0fb201d783ff$75096c90$5f1c45b0$@insyde.com> <20210804110321.ru56hfsyrfrviuwk@leviathan> <10E41009-D3D6-4166-8843-1D04ECA6CC59@apple.com> <16984DDFBF70DC40.16396@groups.io> From: "Maciej Rabeda" In-Reply-To: Content-Type: multipart/alternative; boundary="------------X0pow5CEFGilDlFeEIwulZYv" Content-Language: pl --------------X0pow5CEFGilDlFeEIwulZYv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > > --------------X0pow5CEFGilDlFeEIwulZYv Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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

 


--------------X0pow5CEFGilDlFeEIwulZYv--