From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::232; helo=mail-it0-x232.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 9EE7020D7ADD3 for ; Sat, 21 Jul 2018 08:51:16 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 72-v6so18576436itw.3 for ; Sat, 21 Jul 2018 08:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Y8El9dtwkYESqtYOdztBeSUOTOJI4LuiJGdvWTtRa30=; b=U6ZuKEr7wyJhpXwmL44RXV9RNn/xr39c/Z6k/GYV0If7gfWlv8XQJlJ5MjlQtpqiP+ JPr3+K6YOxAI2Nlnq01eKydHb+r94a/BKvRKRQ4ZsOG5Xed4ccPNgcNPJec8BN/D/zLq WFMoy7uTyz9gbJ2MMLiW3K2ogBjb1GZJN8IoE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y8El9dtwkYESqtYOdztBeSUOTOJI4LuiJGdvWTtRa30=; b=C4n5Fk/KYOeBPBx4Av3zAe0sZGZWXhAMUqbJKVxTx/4UmZ08obNVItbksjl6hJXnvZ 0vu0MCyE9FDznOVP7RNPZq32Q+H4zVB3HS47EZt/zV0yya9SR85A6ppRjQS/rNvGoUS3 eVMQ1qMZ71nJhyhNQMx7vr32W+zmdqrbB2J8Cw7DT0YnqK+UCBtPz65QsiXFhVboMnDQ 9Zft+BWbZFAIw9zfxHVT/+ukVtD6tLfzFDUCCSTIrzUG8+EgnfeNd5z2GxevsK7VPoUr oSryf/KizAz4/ijJU6/KDTlYTupD1v4tX0JwdNvDh34bJcTFA/YjteQZ7h0QFqMKjBlF XXkg== X-Gm-Message-State: AOUpUlGf5dc2ncD6/HKxLtYatD9AfKLiuIPGwwWvwbm2WfXMt7d/SE+d rTIz6gbjNLmm72aqoMEXcpZVshwFZ9c9Oe724HEpKv63 X-Google-Smtp-Source: AAOMgpfgKi75raI6an62D6adNKmWF130zKKo+n0aL2gimW1HxLSG0YHK/Mp+yRSeZIHSMaAKdHoi7kqoSprzRpTojNI= X-Received: by 2002:a24:610d:: with SMTP id s13-v6mr5420092itc.68.1532188275745; Sat, 21 Jul 2018 08:51:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:ac05:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 08:51:15 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Sun, 22 Jul 2018 00:51:15 +0900 Message-ID: To: "Marvin H?user" Cc: "edk2-devel@lists.01.org" , "achin.gupta@arm.com" , "jiewen.yao@intel.com" , "supreeth.venkatesh@arm.com" Subject: Re: StandaloneMmPkg comments X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 15:51:16 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 21 July 2018 at 03:57, Marvin H?user wrote: > Good day, > > I have been reading through the recently imported StandaloneMmPkg and fou= nd three odd things. > > > 1. GUID prefixes: GUIDs defined in StandaloneMmPkg.dec either have no = common prefix at all ("gMmFv") or use the "gEfi" prefix. Maybe the MdeModul= ePkg-style "gEdkii" prefix could be used for a uniform style? The gEdkii prefix is used for GUIDs that are not defined in the PI or UEFI specs. The gEfi prefix is used for GUIDs that are defined in either of those specs. I'm not sure what the rule is for prefixless GUIDs though. > 2. The "gEfiMmConfigurationProtocolGuid" name is common between Standa= lone (StandaloneMmPkg.dec) and Traditional (MdePkg.dec) MM context despite = having a different value of course. Shouldn't the naming reflect which is t= raditional and which is Standalone? I haven't checked in depth, but which i= s chosen when a module consumes both MdePkg and StandaloneMmPkg? That smells like a bug to me. > 3. While .dec already uses the "Mmram" naming scheme, its header decla= res the MemoryReserve GUID as "gEfiMmPeiS(!)mramMemoryReserveGuid". Further= more, the header references the SMM CIS (which has been replaced with "MM C= IS" as part of the renaming), while the GUID has changed and the structure = does not match the deprecated specification anyway. May I suggest to turn t= his GUID into a "gEdkii"-style GUID and remove all references to the SMM CI= S? Maybe use the "EDKII_" prefix for "EFI_MMRAM_HOB_DESCRIPTOR_BLOCK" too? = I wanted to prepare a patch, but I cannot compile the package at the moment= and don't want to risk submitting anything broken. > As mentioned above, EDKII prefixes are inappropriate here, since standalone MM is defined in the PI spec. I will let others comment on the SMM CIS thing.