From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by mx.groups.io with SMTP id smtpd.web11.8230.1589297366182664165 for ; Tue, 12 May 2020 08:29:26 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=NXtXLQSQ; spf=pass (domain: nuviainc.com, ip: 209.85.128.68, mailfrom: leif@nuviainc.com) Received: by mail-wm1-f68.google.com with SMTP id z72so14259820wmc.2 for ; Tue, 12 May 2020 08:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EQGE9zCWYSoAB5rCxry7tfDNyF3B5IaXUaToMeX1p04=; b=NXtXLQSQDKe9xwAHNr7wPUsoRBvAWUT7iRK+jeMfGTuYSq9sBg7KKZikFmsf1Wp+Wy O5jMIEs5TFz6mPI+2dubivG+7GfwrlhARNpahCCq5tbYYVJduX6J/yKe6U4F/yK+/M6d BYlMyqC3mBjtYdAx3BkZ/Pd/OIcek+Al32R3ZivohR3U0SaHCBbkSYtMzFFA4EJ30txl LkEbTvc0IGCtxMP+tuLGWkXaI2xQt1WG/4qbrVANFs/eOJ1POrh0uTMXBqkSc8dfr/r8 kiKzZlxSMgxBTA71dIEs7ROIgCEdwP7zH+xY9ueXM1eJr/QCXFJe3tJyrf5wk7euG73z MRyw== 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=EQGE9zCWYSoAB5rCxry7tfDNyF3B5IaXUaToMeX1p04=; b=bJEzHM9bQVGIyxP6RnZv7NIdjeTsmPhOKdbhp2S2K0JUgJpzfgos095ilVmBtxyKyL oxnlbwmr/j7IsSoRRPKvF6JXoH1kBPjicwT8LelaXFR+eUxKBvJQ6qeCzfIghDFyUM/D Ry64GWxZppHLs8w0ZKnKmOnQPSXR8lZAPQZXDFp06vVkW89CCaSkm54MwJsha+iLmmGy kyAQjZr0JBN1lPTDue3917DjvJxPfhp4ADeV6kiMXl7S0XcsiUvce2vhKgOZTWNuGdG8 dNcmleFTp6Jm8OzGQ010anIrpQY5PxY4LFJRnps45l6TNi3zIn6wgmRxex7KjTp/Az5U vGEA== X-Gm-Message-State: AGi0PuaR5NofG9EJDRoBO4kh7QPU4hgcIkY1sY57r72M9fz9qodZpCyk gK9r+VTR7hiP0sYF+PkYs309/g== X-Google-Smtp-Source: APiQypICZQUQRAINgY05MceeCUJCdLn7eGwHwziNc5SQZshQir0QMt600Wa7ksXUO2b4B/g8qcEA2g== X-Received: by 2002:a1c:4e0e:: with SMTP id g14mr8983285wmh.0.1589297364751; Tue, 12 May 2020 08:29:24 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id h20sm11454727wma.6.2020.05.12.08.29.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2020 08:29:24 -0700 (PDT) Date: Tue, 12 May 2020 16:29:22 +0100 From: "Leif Lindholm" To: "Ni, Ray" Cc: "rfc@edk2.groups.io" , "devel@edk2.groups.io" , Felix Polyudov , "Doran, Mark" , Andrew Fish , Laszlo Ersek , "Kinney, Michael D" , Samer El-Haj-Mahmoud Subject: Re: [edk2-rfc] [RFCv2] code-first process for UEFI-forum specifications Message-ID: <20200512152922.GL21486@vanye> References: <20200323190548.GF22097@bivouac.eciton.net> <734D49CCEBEEF84792F5B80ED585239D5C4B2676@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C4B2676@SHSMSX104.ccr.corp.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 25, 2020 at 05:14:59 +0000, Ni, Ray wrote: > > > > ## Github > > New repositories will be added for holding the text changes and the source code. > > > > Specification text changes will be held within the affected source repository, > > in the Github flavour of markdown, in a file (or split across several files) > > with .md suffix. > > What's the case when multiple .MD files are needed? For example if a branch covers changes to multiple specifications, as described elsewhere. Or if it simply makes sense due to content size. It is possible, now we've migrated to .rst for edk2, that we should change the format recommentded in this proposal too. > > (This one may break down where we have a specification change affecting multiple > > specifications, but at that point we can track it with multiple BZ entries) > > > > > > > ## Source code > > In order to ensure draft code does not accidentally leak into production use, > > and to signify when the changeover from draft to final happens, *all* new or > > modified[1] identifiers need to be prefixed with the relevant BZ####. > > > > [1] Modified in a non-backwards-compatible way. If, for example, a statically > > sized array is grown - this does not need to be prefixed. But a tag in a > > comment would be *highly* recommended. > > If a protocol is enhanced to provide more interfaces with increased revision number, > would you like the protocol name to be prefixed with BZ####? > Or just the new interfaces added to the protocol are prefixed the BZ####? > I think just prefixing the new interfaces can meet the purpose. Adding new interfaces to a protocol does not affect its backwards-compatibility, which was what I was trying to cover above. If you can think of a better way of describing it. I am very open to suggestions. > But the protocol definition is changed, it also needs to be prefixed according to this flow. > Can you clarify a bit more? In that instance, only the new interfaces would need the prefix. > > > > ### File names > > New public header files need the prefix. I.e. `Bz1234MyNewProtocol.h` > > Private header files do not need the prefix. > > > > ### Contents > > > > The tagging must follow the coding style used by each affected codebase. > > Examples: > > > > | Released in spec | Draft version in tree | Comment | > > | --- | --- | --- | > > | `FunctionName` | `Bz1234FunctionName` | | > > | `HEADER_MACRO` | `BZ1234_HEADER_MACRO` | | > > If FunctionName or HEADER_MACRO is defined in non-public header files, I don't > think they require the prefix. Do you agree? Only public interfaces need prefix. This also means that non-public interfaces should be STATIC where possible. > > For data structures or enums, any new or non-backwards-compatible structs or > > fields require a prefix. As above, growing an existing array in an existing > > struct requires no prefix. > > > > | `typedef SOME_STRUCT` | `BZ1234_SOME_STRUCT` | Typedef only [2] | > > | `StructField` | `Bz1234StructField` | In existing struct[3] | > > | `typedef SOME_ENUM` | `BZ1234_SOME_ENUM` | Typedef only [2] | > > > > [2] If the struct or enum definition is separate from the typedef in the public > > header, the definition does not need the prefix. > > What does "separate" mean? > Does it mean "struct or enum in the public header BzXXX.h don't need the prefix"? > If yes, then I think macros defined in BzXXX.h also don't need the prefix. Struct or enum definitions in the public header BzXXX.h don't need the prefix *when they have a public-facing typedef with the prefix*. Everything new or not-backwards-compatible needs to be referred to via the prefixed names in external modules. I.e. we can have struct _SomeNewThing { }; typedef struct _SomeNewThing BzXXX_PROTOCOL; (This is meant simply as shorthand, reducing the amount of changes required for the published version.) > > [3] Individual fields in newly added typedefd struct do not need prefix, the > > struct already carried the prefix. > > > > Variable prefixes indicating global scope ('g' or 'm') go before the BZ prefix. > > > > | `gSomeGuid` | `gBz1234SomeGuid` | | > > > > Local identifiers, including module-global ones (m-prefixed) do not require a > > BZ prefix. > > I think only the names (struct type name, enum type name, interface name, protocol/ppi name) > defined in public header files need the BZ prefix when the public header doesn't have prefix. > Right? That is one way we *could* do it. It is not one I am proposing. My idea is that it should be very clear from looking at code whether it includes non-ratified proposal code. / Leif