From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web12.26221.1639490366177493617 for ; Tue, 14 Dec 2021 05:59:26 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=PWcVgsDB; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 829E6B819C9 for ; Tue, 14 Dec 2021 13:59:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45D88C34616 for ; Tue, 14 Dec 2021 13:59:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639490361; bh=uQHFKZ1C8cljrw8dJCvOaBIcSUdKNFs+XbYFtzBAYNg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=PWcVgsDB1jegF3dCKbwijuOZ3x9T50bv+qCp0/XNPMplBQZhaDVBn2LCVSNCFGUK2 sRavn74u0LeKGt9phu5httHUiUuSXXsPypkQO6UDd3KDMx54lKZFI4U3C+iT7+i7qK grw5X9/t4CU/q9OyqcfhY7HLL7+nUVRLSHfOqpXh+W3iQqn1wX0FHvU0BO5l1GVTUl H+3ZZuGVzrTfhF39hUm3NfxO8YdXopuczn0INYjUWhjokGVXZoRoCLT5GX1z5tS6vF /r/V/mTfZuKwcYo2R+5KCkPikS+pd+gGrzZEPghVtPOcX8+rgIiJcccJiXCBzbLSVy OrNt4xkrfuNyQ== Received: by mail-ot1-f48.google.com with SMTP id x43-20020a056830246b00b00570d09d34ebso20942130otr.2 for ; Tue, 14 Dec 2021 05:59:21 -0800 (PST) X-Gm-Message-State: AOAM533Jisfg2gQQsWjbXFTBB9PZgwCqGxzaBvbfW7H93bDS2Cr+nIbS cwM/l03E01ypUGrgiwW7B/4sdRCeBBe4o4WF034= X-Google-Smtp-Source: ABdhPJwfNcOiS9cLs19Qp7s10KOa+0Ixbm5Ef+0uqTUpky82+0YolA5fLv3gWWfxTV1Sxq/nncWpOMQ/uTvVKvqVX6w= X-Received: by 2002:a05:6830:1514:: with SMTP id k20mr4259216otp.147.1639490360528; Tue, 14 Dec 2021 05:59:20 -0800 (PST) MIME-Version: 1.0 References: <20211214134126.869-1-min.m.xu@intel.com> <20211214134126.869-4-min.m.xu@intel.com> In-Reply-To: <20211214134126.869-4-min.m.xu@intel.com> From: "Ard Biesheuvel" Date: Tue, 14 Dec 2021 14:59:09 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 03/10] EmbeddedPkg/MemoryAllocationLib: Add null stub for AllocateCopyPool To: edk2-devel-groups-io , Min Xu Cc: Michael D Kinney , Brijesh Singh , Erdem Aktas , James Bottomley , Jiewen Yao , Tom Lendacky , Gerd Hoffmann , Leif Lindholm , Ard Biesheuvel , Abner Chang , Daniel Schaefer Content-Type: text/plain; charset="UTF-8" On Tue, 14 Dec 2021 at 14:42, Min Xu wrote: > > RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 > > This function is a null stub to make the build success. > > Cc: Michael D Kinney > Cc: Brijesh Singh > Cc: Erdem Aktas > Cc: James Bottomley > Cc: Jiewen Yao > Cc: Tom Lendacky > Cc: Gerd Hoffmann > Cc: Leif Lindholm > Cc: Ard Biesheuvel > Cc: Abner Chang > Cc: Daniel Schaefer > Signed-off-by: Min Xu > --- > .../MemoryAllocationLib.c | 28 +++++++++++++++++++ > 1 file changed, 28 insertions(+) > Why is it justified to implement a broken version of this routine? This is not a NULL library class that only exists for build test purposes, it is actually used in production builds. If the TDVF code needs the symbol but does not actually call it, perhaps there is another place where this should get fixed? > diff --git a/EmbeddedPkg/Library/PrePiMemoryAllocationLib/MemoryAllocationLib.c b/EmbeddedPkg/Library/PrePiMemoryAllocationLib/MemoryAllocationLib.c > index 78f8da5e9527..ddc27150c680 100644 > --- a/EmbeddedPkg/Library/PrePiMemoryAllocationLib/MemoryAllocationLib.c > +++ b/EmbeddedPkg/Library/PrePiMemoryAllocationLib/MemoryAllocationLib.c > @@ -220,6 +220,34 @@ AllocateZeroPool ( > return Buffer; > } > > +/** > + Copies a buffer to an allocated buffer of type EfiBootServicesData. > + > + Allocates the number bytes specified by AllocationSize of type EfiBootServicesData, copies > + AllocationSize bytes from Buffer to the newly allocated buffer, and returns a pointer to the > + allocated buffer. If AllocationSize is 0, then a valid buffer of 0 size is returned. If there > + is not enough memory remaining to satisfy the request, then NULL is returned. > + > + If Buffer is NULL, then ASSERT(). > + If AllocationSize is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT(). > + > + @param AllocationSize The number of bytes to allocate and zero. > + @param Buffer The buffer to copy to the allocated buffer. > + > + @return A pointer to the allocated buffer or NULL if allocation fails. > + > +**/ > +VOID * > +EFIAPI > +AllocateCopyPool ( > + IN UINTN AllocationSize, > + IN CONST VOID *Buffer > + ) > +{ > + ASSERT (FALSE); > + return NULL; > +} > + > /** > Frees a buffer that was previously allocated with one of the pool allocation functions in the > Memory Allocation Library. > -- > 2.29.2.windows.2 > > > > > >