From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.66; helo=nwk-aaemail-lapp01.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 AB6B9211B81A0 for ; Wed, 16 Jan 2019 14:18:33 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x0GMCfeP019123; Wed, 16 Jan 2019 14:18:33 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=8qO/utuyvwMJ0765F48R9KVeRfETvj8ETU9eYXAblf8=; b=GCklfA3lN+hzSeW3PN09ynkJ0RyLKoIvtlt2Rj2gj9RZi4VFaQ1Jg4MmCP6zQ/ucv3Xc EEznza6rNLMNIa/xfvFKgEmJi42lxcaDP+uJHV63/JXcmwbbBtGRyQPwTEkkZ16UWIGe N3cyLDX0tXR19rTrZg6lZS4dT6KVx1pXub7A5pirzFcPwDJ+wacHt1b7Aoz/MFBMI6jj 9n41JYblBxYV5QuB6wi3C8kYpF1m1IcFYkBJUYvYgqr6G5CpZfV8M7jKKg/XutOU9pPT p7ntSJEXnSeijoRqmD5VkKgLy6o4XOedVy678jNyC0N+d4BguHVe17v4ZEv4d8GPkSTN 9w== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2pyg270xam-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Jan 2019 14:18:33 -0800 MIME-version: 1.0 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PLG00GSF3AULI80@ma1-mtap-s03.corp.apple.com>; Wed, 16 Jan 2019 14:18:30 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PLG00K003885C00@nwk-mmpp-sz12.apple.com>; Wed, 16 Jan 2019 14:18:30 -0800 (PST) X-Va-A: X-Va-T-CD: da3a4df698400084da27c6ab403bcb35 X-Va-E-CD: 342cf6fca028c928aa9ec40d8313e2d6 X-Va-R-CD: dd8e83747d7798cbaa767a47f53eace0 X-Va-CD: 0 X-Va-ID: a3cfda59-dd93-44f3-a51d-9ad534a55ac7 X-V-A: X-V-T-CD: da3a4df698400084da27c6ab403bcb35 X-V-E-CD: 342cf6fca028c928aa9ec40d8313e2d6 X-V-R-CD: dd8e83747d7798cbaa767a47f53eace0 X-V-CD: 0 X-V-ID: 43461421-384a-4f94-90e6-bccc4bfd04ba Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PLG00K0037X4Y00@nwk-mmpp-sz12.apple.com>; Wed, 16 Jan 2019 14:18:30 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-01-16_09:,, signatures=0 Received: from [17.226.41.14] (unknown [17.226.41.14]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PLG00HAZ3AUWN20@nwk-mmpp-sz12.apple.com>; Wed, 16 Jan 2019 14:18:30 -0800 (PST) Sender: afish@apple.com From: Andrew Fish In-reply-to: Date: Wed, 16 Jan 2019 14:18:05 -0800 Cc: "edk2-devel@lists.01.org" Message-id: <37D3156D-0434-4A64-BF0C-9883A4B88838@apple.com> References: To: Mike Kinney X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-16_09:, , signatures=0 Subject: Re: History question about Base.h and its alternate parallel name space.... Should we change it? 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: Wed, 16 Jan 2019 22:18:33 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Jan 16, 2019, at 1:19 PM, Kinney, Michael D wrote: > > Hi Andrew, > > I though the reason was a bit more technical. We have a > MODULE_TYPE of BASE. Library instances that use the BASE > MODULE_TYPE are declaring that the library interfaces are > safe to be linked against a module of any other type (SEC, > PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP). > > We needed to make sure that a lib of type BASE that > includes Base.h as its top level include file only has > visibility to the types that are safe for all the other > module types. It is up to the top level include files > for these other module types to provide the gasket to > the types in Base.h. > > If we add aliases in Base.h, then we may not get build > breaks when a lib of type BASE includes files that are > not compatible with BASE. > Mike, I don't think having aliases for return types really helps Base code quality as RETURN_SUCCESS is almost always just a comment in a header file, and only exists in a .c file. Thus RETURN_* seem like a needless duplication, best case it is a comment that the code is Base. I will agree that not having EFI_GUID defined does case all the PPI and Protocol files to blow up if you try to include them. The failure case I was helping explain was some one trying to include a PPI, that included a Protocol that contained a data structure that was needed. But I would posit that the definition of a (EFI_)GUID is state agnostic. Having access to a PPI or Protocol definition does not break Base code, what breaks Base code is trying to access some service that does not exist. To get more that EFI_GUID you are going to need to include Uefi.h, PiPei.h, PiDxe.h, etc. and that will block doing anything that is not Base. So I'm asking if redefining the name for EFI_GUID to GUID for Base is really that helpful? Thanks, Andrew Fish > Thanks, > > Mike > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel- >> bounces@lists.01.org] On Behalf Of Andrew Fish via edk2- >> devel >> Sent: Wednesday, January 16, 2019 1:00 PM >> To: edk2-devel >> Subject: [edk2] History question about Base.h and its >> alternate parallel name space.... Should we change it? >> >> I had some one ask me recently why EFI_GUID does not >> work with #include . I explained they needed to >> use GUID vs. EFI_GUID. That prompted the question of why >> we have 2 names for the same thing..... Well the >> historical answer was kind of political as some team >> wanted to use edk2, but not implement EFI. Thus we have >> EFI types without the EFI_ prefix in Base.h. >> >> So all this got me thinking.... Maybe it makes sense to >> move some of the renaming from >> MdePkg/Include/Uefi/UefiBaseType.h to Base.h? Removing >> the Base.h duplicate types would potentially hit lots of >> code [1] and break merges with other code bases (break >> other peoples Base libs etc.). >> >> These lines in MdePkg/Include/Uefi/UefiBaseType.h would >> get moved to MdePkg/Include/Base.h: >> typedef GUID EFI_GUID; >> typedef RETURN_STATUS EFI_STATUS; >> #define EFIERR(_a) ENCODE_ERROR(_a) >> #define EFI_ERROR(A) RETURN_ERROR(A) >> >> #define EFI_SUCCESS RETURN_SUCCESS >> #define EFI_LOAD_ERROR RETURN_LOAD_ERROR >> #define EFI_INVALID_PARAMETER >> RETURN_INVALID_PARAMETER >> #define EFI_UNSUPPORTED RETURN_UNSUPPORTED >> #define EFI_BAD_BUFFER_SIZE RETURN_BAD_BUFFER_SIZE >> #define EFI_BUFFER_TOO_SMALL >> RETURN_BUFFER_TOO_SMALL >> #define EFI_NOT_READY RETURN_NOT_READY >> #define EFI_DEVICE_ERROR RETURN_DEVICE_ERROR >> #define EFI_WRITE_PROTECTED RETURN_WRITE_PROTECTED >> #define EFI_OUT_OF_RESOURCES >> RETURN_OUT_OF_RESOURCES >> #define EFI_VOLUME_CORRUPTED >> RETURN_VOLUME_CORRUPTED >> #define EFI_VOLUME_FULL RETURN_VOLUME_FULL >> #define EFI_NO_MEDIA RETURN_NO_MEDIA >> #define EFI_MEDIA_CHANGED RETURN_MEDIA_CHANGED >> #define EFI_NOT_FOUND RETURN_NOT_FOUND >> #define EFI_ACCESS_DENIED RETURN_ACCESS_DENIED >> #define EFI_NO_RESPONSE RETURN_NO_RESPONSE >> #define EFI_NO_MAPPING RETURN_NO_MAPPING >> #define EFI_TIMEOUT RETURN_TIMEOUT >> #define EFI_NOT_STARTED RETURN_NOT_STARTED >> #define EFI_ALREADY_STARTED RETURN_ALREADY_STARTED >> #define EFI_ABORTED RETURN_ABORTED >> #define EFI_ICMP_ERROR RETURN_ICMP_ERROR >> #define EFI_TFTP_ERROR RETURN_TFTP_ERROR >> #define EFI_PROTOCOL_ERROR RETURN_PROTOCOL_ERROR >> #define EFI_INCOMPATIBLE_VERSION >> RETURN_INCOMPATIBLE_VERSION >> #define EFI_SECURITY_VIOLATION >> RETURN_SECURITY_VIOLATION >> #define EFI_CRC_ERROR RETURN_CRC_ERROR >> #define EFI_END_OF_MEDIA RETURN_END_OF_MEDIA >> #define EFI_END_OF_FILE RETURN_END_OF_FILE >> #define EFI_INVALID_LANGUAGE >> RETURN_INVALID_LANGUAGE >> #define EFI_COMPROMISED_DATA >> RETURN_COMPROMISED_DATA >> #define EFI_HTTP_ERROR RETURN_HTTP_ERROR >> >> #define EFI_WARN_UNKNOWN_GLYPH >> RETURN_WARN_UNKNOWN_GLYPH >> #define EFI_WARN_DELETE_FAILURE >> RETURN_WARN_DELETE_FAILURE >> #define EFI_WARN_WRITE_FAILURE >> RETURN_WARN_WRITE_FAILURE >> #define EFI_WARN_BUFFER_TOO_SMALL >> RETURN_WARN_BUFFER_TOO_SMALL >> #define EFI_WARN_STALE_DATA RETURN_WARN_STALE_DATA >> #define EFI_WARN_FILE_SYSTEM >> RETURN_WARN_FILE_SYSTEM >> >> I'm interested what folks think about a change like >> this? This change makes the alternate names optional. >> >> I guess we could also leave the old Base.h definitions >> in Base.h and cleanup the code to only use the EFI form, >> but that is a much bigger change? >> >> [1] RETURN_SUCCSS usage: git grep -w RETURN_SUCCESS >> >> Thanks, >> >> Andrew Fish >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel