> On Oct 12, 2018, at 11:30 AM, Kinney, Michael D <[email protected]>
> wrote:
>
>> -----Original Message-----
>> From: edk2-devel [mailto:[email protected]
>> <mailto:[email protected]>]
>> On Behalf Of Leif Lindholm
>> Sent: Friday, October 12, 2018 11:06 AM
>> To: Laszlo Ersek <[email protected] <mailto:[email protected]>>
>> Cc: [email protected] <mailto:[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.
>
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
>> [email protected] <mailto:[email protected]>
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> <https://lists.01.org/mailman/listinfo/edk2-devel>
> _______________________________________________
> edk2-devel mailing list
> [email protected] <mailto:[email protected]>
> https://lists.01.org/mailman/listinfo/edk2-devel
> <https://lists.01.org/mailman/listinfo/edk2-devel>
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
