> -----Original Message----- > From: edk2-devel [mailto:[email protected]] > On Behalf Of Leif Lindholm > Sent: Friday, October 12, 2018 11:06 AM > To: Laszlo Ersek <[email protected]> > Cc: [email protected] > Subject: Re: [edk2] TianoCore Community Meeting Minutes > > On Fri, Oct 12, 2018 at 06:07:01PM +0200, Laszlo Ersek > wrote: > > On 10/12/18 15:27, Leif Lindholm wrote: > > > On Thu, Oct 11, 2018 at 10:43:57AM -0700, stephano > wrote: > > > > >> Switching to Standard C Types > > >> ----------------------------- > > >> Both Shawn and Nate mentioned that the current > system has been in place for > > >> a long time and some people prefer the current > setup. I can start an email > > >> discussion around this issue specifically if anyone > feels strongly that we > > >> should be using standard types. > > > > > > So, I don't think we made it this far down the agenda > on the US-EU > > > call. > > > > > > One way would be to simply explicitly permit it, > possibly with the > > > constraint that every module needs to pick one and > stick with it, > > > unless people object. > > > > > > I think we'll want to discuss this in a US-EU call as > well. > > > > I'm playing devil's advocate here -- because, in > general, I'm a fan of > > sticking with standard C as much as possible --, but I > see a big > > obstacle in the way. > > > > That obstacle is "Table 5. Common UEFI Data Types", in > the UEFI spec. > > Until a good portion of that table is expressed in > terms of standard C > > types as well (expanding upon the current definitions), > possibly in an > > edk2-level spec (i.e. not necessarily in the UEFI spec > itself), I think > > there's no chance to enable standard C types in edk2 > *meaningfully*. > > > > Because, as soon as you have to call a PI or UEFI > interface, you'll have > > to stick with the PI/UEFI spec types anyway. > > I don't necessarily see that as an issue. But it is a > good point that > it can't just be the codebase changing. > > Since we are however extremely specificly not looking to > change the > underlying storage types, all it would take would be to > make a > 2-column table into a 3-column table in both specs. Or > just add a > separate table for the mapping. Then edk2 could adopt the > "permitted" > rule as soon as the specs were out. Arguably (because > we're not > changing underlying types) we could do it before, but we > _are_ > supposed to be the reference implementation, so it would > be poor form.
I agree that it would be best if the specs list synonymous type names. We would have to guarantee in the edk2 implementation that they types are identical. One potential issue is support for really old compilers. If we can decide to only support compilers that fully support the synonymous types, then that would be clean. Not sure what the ANSI C equivalents are for INTN/UINTN on all compilers. > > > >> Using Git Submodules (like we do with OpenSSL) > > >> -------------------- > > > > > > We didn't make it here either. What would we use it > _for_? > > > I think the openssl case makes a lot of sense, but > what else? > > > > We embed a bunch of other projects (libraries, mainly): > > - Oniguruma > > - Brotli > > - fdt > > - LZMA SDK > > - ... > > Sure. But do we know that is what was meant? > > I certainly recall the "each package should be a > submodule" idea from > a (much) earlier conversation, and would like to ensure > we're not > resurrecting that. Yes. Those other projects was the brief discussion. Not submodule per package. > > Regards, > > Leif > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
