Re: TianoCore Community Meeting Minutes

[Andrew Fish <afish@apple.com>]

> On Oct 12, 2018, at 11:30 AM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:
> 
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org <mailto:edk2-devel-bounces@lists.01.org>]
>> On Behalf Of Leif Lindholm
>> Sent: Friday, October 12, 2018 11:06 AM
>> To: Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>
>> Cc: edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>> 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.
> 

Mike,

INTN -> intptr_t
UINTN -> uintptr_t

If I understand correctly the types we are talking about are defined via stdint.h. Thus if we are a freestanding (__STDC_HOSTED__ == 0) project and we did not include stdint.h we would need to define them in the edk2 headers? 

If the edk2 App/Driver is also including stdint.h we would need some way to avoid conflicts. Likely including stdint.h from ProcessorBind.h in place of defining the values. 


Thanks,

Andrew Fish

>> 
>>>>> 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
>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>