On Fri, Mar 31, 2023 at 12:32 AM Kinney, Michael D <michael.d.kin...@intel.com> wrote: > Appreciate the feedback. Agree that any libc API that is implemented in a > wrapper should conform to the standard. > > > We also have a whole libc implementation in edk2-libc that seems to be > > permanently gathering dust until Intel touches it for Python purposes > > from time to time. So between crypto, libfdt, etc, could we try to > > unify things here a bit? > > edk2-libc to too large for FW components and it is out of date. > > Would you like to volunteer to lead a design and implementation that > is right-sized for FW modules and could be the one wrapper that works > for all current use cases and could be extended in the future as > needed to support additional use cases? Don’t need all of libc. Just > enough to support the APIs used by the submodules used so far. >
Mike, I wrote up a quick RFC patch for a bunch of libc bits that you needed in this case (BaseFdtLib and libfdt). It's very much a WIP and only supports GCC/clang. MSVC needs some support when it comes to limits.h (because of LP64 vs Windows's LLP64), but nothing too hard certainly. See https://edk2.groups.io/g/devel/topic/rfc_patch_1_1_mdepkg_add_a/97965830?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,97965830,previd%3D1680229851681438282,nextid%3D1680190220621190228&previd=1680229851681438282&nextid=1680190220621190228 Comments welcome. -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102229): https://edk2.groups.io/g/devel/message/102229 Mute This Topic: https://groups.io/mt/97955736/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
