-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create crypto binaries report #122
base: release/202311
Are you sure you want to change the base?
Create crypto binaries report #122
Conversation
|
||
def get_module_type_for_crypto_bin(self, thebuilder): | ||
|
||
CryptoBinPkg_Driver_path = Path(thebuilder.ws) / "CryptoBinPkg" / "Driver" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would probebly define CryptoBinPkg_Driver_path
(along side other enrvironment-dependent params) in the beginning of the program to make it visible, so that if changed can be changed in one place.
|
||
class ReportCrypto(IUefiBuildPlugin): | ||
|
||
def do_post_build(self, thebuilder): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Flickdm, @DorLevi95, @kenlautner - generally speaking, I think it might be worth adopting Doxygen decomentation style (for python, described here) for future projects, so that we can use that to auto-gen decomentation site for the tools. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@inbal2l @DorLevi95 Great comment! Usually we inherit our python coding standards from
edk2toollib and try to adhere to google python style and use Ruff for opininated code formatting. We should be able to use mkdocs + some extensions to generate documentation like edk2-pytool-lib
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DorLevi95 could you add function comments :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Dor! This looks great and super useful!
|
||
class ReportCrypto(IUefiBuildPlugin): | ||
|
||
def do_post_build(self, thebuilder): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@inbal2l @DorLevi95 Great comment! Usually we inherit our python coding standards from
edk2toollib and try to adhere to google python style and use Ruff for opininated code formatting. We should be able to use mkdocs + some extensions to generate documentation like edk2-pytool-lib
SingleFlavorBuild.py
Outdated
@@ -42,13 +42,17 @@ def AddCommandLineOptions(self, parserObj): | |||
parserObj.add_argument("-b", "--bundle", dest="bundle", action="store_true", | |||
default=False, | |||
help="Bundles the build output into the directory structure for the Crypto binary distribution.") | |||
parserObj.add_argument("-r", "--report", dest="report", action="store_true", | |||
default=False, | |||
help="produces a report regarding the built crpyto binaries.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
help="produces a report regarding the built crpyto binaries.") | |
help="produces a report regarding the built crypto binaries.") |
report.append("<------Openssl configuration report------>\n") | ||
|
||
# get openssl library files | ||
openssl_lib = Path(thebuilder.edk2path.GetAbsolutePathOnThisSystemFromEdk2RelativePath("OpensslPkg")) / "Library" / "OpensslLib" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this to the top in case we need to easily change this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same with other instances
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
@@ -158,6 +159,7 @@ stages: | |||
BUILDLOG_CryptoBin_*.txt | |||
SETUPLOG.txt | |||
UPDATE_LOG.txt | |||
Report_STANDARD_DEBUG_VS2022.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to save the Release version as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
report_file_name = f"Report_{thebuilder.flavor}_{target}_{tool_chain}.txt"
This would appear to suggest that we need to handle flavor, target, tool_chain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The report can be created for each of these 3 configurations (using --report flag)
I triggered it in the Crypto Test pipeline which currently just builds this specific combination.
Besides of the binary sizes, nothing else in the report is different between different flavors, target, toolchain
|
||
# Get the number of k bytes of the compressed data | ||
compressed_data_size = len(compressed_data) / 1024 | ||
# log to file (assuming file name won't be longer than 40 characters to keep the report clean) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe throw an exception if this assumption is invalid
# get module type for the binary | ||
module_type = binary_to_type.get(file.name, "UEFI_APPLICATION") # Default to UEFI_APPLICATION if not found (e.g. test binary) | ||
opensslib = self.get_linked_lib(thebuilder, arch, module_type, "OpensslLib") | ||
report.append(f"{file.name} - " + (40-len(file.name))* " " + f"OpensslLib: {opensslib}\n") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same assumption that the file name won't be longer than 40 characters
openssl_inf_files.sort() | ||
for file in openssl_inf_files: | ||
# write openssl library files to report file | ||
openssl_flags = self.get_openssl_flags(file) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: Would it be possible to map the flags to a human readable form? Or do you think that these would change / introduce too much complexity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be interesting if we have a list of "required" flags and if one is missing that it throws an exception
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first suggestion sounds to indeed introduce more complexity. We would need to create a mapping between all the possible flags and their human read descriptions.
Most flags can be understood for their name.
The second suggestion sounds good.
The future comparison too is the one who aims to throw warnings for each change in the flags found in PR.
I don't know if we would want to change in to throw error OR throw it already in the reporting tool. As this would fail the build/pipeline (depends on which tool), and that might be what the user intended.
Moreover, if we would go down to it, do we have such pre-defined required flags?
|
||
class ReportCrypto(IUefiBuildPlugin): | ||
|
||
def do_post_build(self, thebuilder): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DorLevi95 could you add function comments :)
Description
Creating a reporting script to run in post build.
This script will generate a report about the crypto binaries containing useful info:
The report will be placed in the build folder with the name "Report_" and published during Crypto tests pipeline.
A follow up PR needs to be added, which will compare reports during each PR (latest release branch report as the baseline report) and produce necessary warnings.
The goal is to catch risky changes that can break functionality or influence the memory consumption (e.g. increase or decrease in size).
Currently the report is only generated and publish during the Crypto tests pipeline. i.e. STANDARD_DEBUG flavor.
This mainly influences only the binaries sizes and might be enough to catch abnormal increase/decrease.
Please refer to this draft PR to view and example of the report and its comparison during a PR: #118