From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::432; helo=mail-wr1-x432.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6C92A2116DA24 for ; Fri, 12 Oct 2018 11:06:33 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id 61-v6so14368411wrb.6 for ; Fri, 12 Oct 2018 11:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rtdqFwXQ2YGdrQKrO+qi+uTPolkZIaQ7OxWKV+k+oaE=; b=fllBqMeaKre90KJUSDNkiYT018VZFhfvesk83OXdVkRsgoyzYR4G+7lK6IxVOQjW6P fqsN43i2b8ZpgV9VLDgpzgOzyX2dV1ZUp8jk0zsffuxBuLUL8Vq4HdA4aTOt8Lbovxhm 2zD9VOpXJLizFXHg+UL5mzDG/Y64feiejX+Ww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rtdqFwXQ2YGdrQKrO+qi+uTPolkZIaQ7OxWKV+k+oaE=; b=B+4hHJUMC9AG3M99F68Db6ZKR/oheuWKfa5LpEr6Bw1Zpx+Uz84g0VfNpUX0XjScQy QBgD20R9epnhewD8DJibuWIPtrjnLXGAEamLNrRLtdRfhS4+Vcj+EqSvN11T/Ol9l1Rt sbXdpEiZe3ZkeItM0ifelezLlF54MhnVZ3IRqFMx/lyu2UpQ0lr+OEShb5+UUN4L+jya LScW1f5O6k/AHEwVrxKwWp7rvpRm+HZZAULTgzdZUGyxwSo8YRja0wyRqwzl8NsnKWye MJwU13K3216oYSfKqZm7XP/2BjQMuBPtGOS4Ikuf0/TmhYickhWNEM3DhaBkBn6glAC4 2Vgg== X-Gm-Message-State: ABuFfojnY0KSAWAHNkEF7Y0YrilMCOdzsNNX+fVvX6HZHdJBTszBpGPq AiSKbUM4ks0deSszuRC6eKdgvg== X-Google-Smtp-Source: ACcGV630PQVJhtqePt5nqWNpU2AtIJ9B99w66uVZ6kgmlUI17bG56bU+lbgQ7xLhVLuStYOSLuZqEw== X-Received: by 2002:a5d:4949:: with SMTP id r9-v6mr5938347wrs.114.1539367592095; Fri, 12 Oct 2018 11:06:32 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id t2-v6sm1997156wrr.7.2018.10.12.11.06.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 Oct 2018 11:06:30 -0700 (PDT) Date: Fri, 12 Oct 2018 19:06:29 +0100 From: Leif Lindholm To: Laszlo Ersek Cc: stephano , edk2-devel@lists.01.org Message-ID: <20181012180629.lltlsiailg6g4hyk@bivouac.eciton.net> References: <20181012132718.mgpg3f42hjulcwfk@bivouac.eciton.net> <180aa195-2e56-06a6-ef66-747e6c3210f7@redhat.com> MIME-Version: 1.0 In-Reply-To: <180aa195-2e56-06a6-ef66-747e6c3210f7@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) 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:06:34 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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