/openbmc/libcper/tests/ |
H A D | base64_test.cpp | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | meson.build | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
/openbmc/libcper/ |
H A D | base64.h | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | base64.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | ir-parse.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | meson.build | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | cper-parse.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
/openbmc/libcper/sections/ |
H A D | cper-section-cxl-component.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | cper-section-ccix-per.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | cper-section-pcie.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | cper-section-dmar-iommu.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | cper-section-dmar-vtd.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | cper-section-cxl-protocol.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | cper-section-ia32x64.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|
H A D | cper-section-arm.c | a7d2cddd Mon Jul 15 13:07:27 CDT 2024 Ed Tanous <etanous@nvidia.com> Move to embedded base64
Base64 encode/decode is a relatively simple algorithm, and currently libcper takes a dependency on libb64 for this. libb64 does not have methods for determining the encoded size or decoded size, and rely on the user to provide the right buffer sizes, which libcper currently approximates as 2X the input size (which is incorrect).
This commit removes the libb64 dependency entirely, and inlines a libcper specific base64 encoder and decoder, using EDK2-allowed types.
The implementation itself is unique to libcper and makes the following design decisions. 1. Malloc is performed within the base64_<> functions. This reduces the number of malloc calls total, and removes the need for separately determining the output size. 2. Arguments are passed in by EDK2-types under the assumption that this will keep compatibility with EDK2 implementations. 3. Incremental parsing is not supported. CPER records are expected to be algorithmically small, and buffered such that the entire value fits in memory. This was already an assumption, but dropping the support for incremental encoding significantly reduces the amount of code to support it. It could be added back in the future if needed.
Change-Id: Idb010db105067ea317dbee05c2663511ab3c6611 Signed-off-by: Ed Tanous <ed@tanous.net>
|