From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.68; helo=ma1-aaemail-dr-lapp02.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CB77A2116DF96 for ; Fri, 12 Oct 2018 12:44:42 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9CJ345B032924; Fri, 12 Oct 2018 12:44:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=893aUsc9p52ZX79tcplBhpkkRqRKjehrxA+D4i0ESK4=; b=BEsM3keYYBr9MWHm+HbkIKmS9fBoMkq+fXq8lzrSz9ZltnK3tDyI8/4Xz85AevwyQRXw t4oerMGtygs3iUsRJ2L0Di9BDg69NnWeuEjmF+gqfo9U/aabcrwJH19lmztgfpvQ7+sa fgb0fuqUKStBwWp4L1umVh2M/usrSoRTBvdiNXVx70u+f8iDfbviglx6HnmAUvNbqXSR 4MX22bwfOimdYSA51hvxnSWSFilh+dGSZSnlu6fkuz3gO6JqD2QT2K/9GnBmLjbfPR/6 vq1jgBUxl4tFKpRZZlSo/DG3xbvNfQo/5DGChO0H3Hzs6V8xrYiZFexYNj+ffpNtkGBK xw== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2mxsr19ccd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Oct 2018 12:44:40 -0700 MIME-version: 1.0 Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGI00F1X46FVOC0@mr2-mtap-s02.rno.apple.com>; Fri, 12 Oct 2018 12:44:39 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGI00A003N9QZ00@ma1-mmpp-sz09.apple.com>; Fri, 12 Oct 2018 12:44:39 -0700 (PDT) X-Va-A: X-Va-T-CD: cdf0b31a85bb8d396f4fbacc2efe7f8e X-Va-E-CD: bfb2777e4756679b1ba5aaadc995d351 X-Va-R-CD: 6a64947708146bea7411e6a6f5086601 X-Va-CD: 0 X-Va-ID: e1d21c5b-590a-46a5-9543-b31c78260e3e X-V-A: X-V-T-CD: da3a4df698400084da27c6ab403bcb35 X-V-E-CD: bfb2777e4756679b1ba5aaadc995d351 X-V-R-CD: 6a64947708146bea7411e6a6f5086601 X-V-CD: 0 X-V-ID: 46c3afa2-03f0-48f9-8672-72ffcb515ad5 Received: from process_milters-daemon.ma1-mmpp-sz09.apple.com by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGI00A003LPBP00@ma1-mmpp-sz09.apple.com>; Fri, 12 Oct 2018 12:44:38 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-12_13:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp21.corp.apple.com-10000_instance1 Received: from [17.234.241.37] (unknown [17.234.241.37]) by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGI0006S46BUD80@ma1-mmpp-sz09.apple.com>; Fri, 12 Oct 2018 12:44:38 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <3DB280A2-A334-49AC-BA6A-550744EDCD04@apple.com> Date: Fri, 12 Oct 2018 12:44:20 -0700 In-reply-to: Cc: Leif Lindholm , Laszlo Ersek , "edk2-devel@lists.01.org" To: Mike Kinney References: <20181012132718.mgpg3f42hjulcwfk@bivouac.eciton.net> <180aa195-2e56-06a6-ef66-747e6c3210f7@redhat.com> <20181012180629.lltlsiailg6g4hyk@bivouac.eciton.net> X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-12_13:, , signatures=0 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: TianoCore Community Meeting Minutes X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:44:43 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > On Oct 12, 2018, at 11:30 AM, Kinney, Michael D wrote: > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org ] >> On Behalf Of Leif Lindholm >> Sent: Friday, October 12, 2018 11:06 AM >> To: Laszlo Ersek > >> Cc: 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 >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel