From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.120; helo=mga04.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 5F5A42116DF85 for ; Fri, 12 Oct 2018 11:30:57 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2018 11:30:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,373,1534834800"; d="scan'208";a="82150223" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by orsmga006.jf.intel.com with ESMTP; 12 Oct 2018 11:30:56 -0700 Received: from orsmsx156.amr.corp.intel.com (10.22.240.22) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 12 Oct 2018 11:30:56 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.89]) by ORSMSX156.amr.corp.intel.com ([169.254.8.164]) with mapi id 14.03.0319.002; Fri, 12 Oct 2018 11:30:56 -0700 From: "Kinney, Michael D" To: Leif Lindholm , Laszlo Ersek , "Kinney, Michael D" CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] TianoCore Community Meeting Minutes Thread-Index: AQHUYYpFiV+xtV6XdE20TO2KgJzXkqUcEN2AgAAsn4CAACFhgP//kA3A Date: Fri, 12 Oct 2018 18:30:55 +0000 Message-ID: References: <20181012132718.mgpg3f42hjulcwfk@bivouac.eciton.net> <180aa195-2e56-06a6-ef66-747e6c3210f7@redhat.com> <20181012180629.lltlsiailg6g4hyk@bivouac.eciton.net> In-Reply-To: <20181012180629.lltlsiailg6g4hyk@bivouac.eciton.net> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.139] MIME-Version: 1.0 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 18:30:57 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----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 >=20 > 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. >=20 > I don't necessarily see that as an issue. But it is a > good point that > it can't just be the codebase changing. >=20 > 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. >=20 > > >> 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 > > - ... >=20 > Sure. But do we know that is what was meant? >=20 > 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. >=20 > Regards, >=20 > Leif > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel