Re: TianoCore Community Meeting Minutes

[Leif Lindholm <leif.lindholm@linaro.org>]

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.

> >> 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.

Regards,

Leif