Re: [edk2-devel] Edk2 BaseTools Patches.
Thanks for your comments. I’ll push the below 2 patches. [PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache [PATCH] BaseTools:Update binary cache restore time to current time I have no strong justification to push this patch in this stable tag. I’ll push it after the tag. [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS FILE I’ll push these 2 patches after the tag also. [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources section [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file Thanks, Bob From: Johnson, Michael Sent: Friday, May 31, 2019 8:03 AM To: devel@edk2.groups.io; af...@apple.com Cc: Leif Lindholm ; Feng, Bob C ; Rodriguez, Christian ; Laszlo Ersek ; Kinney, Michael D ; Gao, Liming ; Shi, Steven ; Fan, ZhijuX Subject: RE: [edk2-devel] Edk2 BaseTools Patches. Andrew, What about the force include of AutoGen.h? AutoGen.h (and .c) have contents which are determined by various metadata like PCD values or items listed in the INF. The sources and dependencies can’t be involved, since those aren’t known until after the autogen files are already complete. The build calls genc before genmake. The hash accounts for those by incorporating the metadata itself, rather than the autogenerated files. If there is a rule the tools should enforce the rule with good error messages. For the case of the build hash feature, we have an EdkLogger.warn in these patches. Invalidating the hash allows the build to continue with up-to-date modules by sending the module back to the regular build process, and the message informs the user of what we found. Since the point of the feature is to speed up builds, I think this is right. If we instead stopped the build, when without --hash it would’ve completed successfully, then we’ve made a more restricted build that’s less useful, rather than giving the existing functionality a speed boost via caching. I’m not against broadening the use of this check to regular builds, but that has unanswered questions and its outside the scope of the BZs targeted by these patches. Do we want to check for this condition on every build and log when we see it? Do we want an optional build flag for it? Should another flag cause a halt and give an error, maybe something like “--strict” which could check for other spec violating conditions as well? It turns into a whole feature of its own, with considerably higher impact since *many* codebases in the wild have non-compliant modules sprinkled throughout. I think Leif and I are both concerned about having two ways to do something as complex as make dependencies, as they risk getting out of phase, or breaking different ways (like following the .h rules in the INF File). I understand the concern. One positive thing about the overly broad nature of hashing all possible legal includes and all compiler flags and all etc etc is that we don’t need to carry much understanding or complexity. We just hash ‘all the inputs’ and don’t bother looking any deeper. Further, when the hash of a module changes, it drops back to the regular path and the ordinary build/skip decision is made exactly as it would be in a regular build. I think this is simple enough to not be (too) troubling. At some point refactoring the build system from the top might be the right approach. Agreed. The build tools are critical and could use more attention. Maybe someday… -Michael From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io Sent: Thursday, May 30, 2019 3:53 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Johnson, Michael mailto:michael.john...@intel.com>> Cc: Leif Lindholm mailto:leif.lindh...@linaro.org>>; Feng, Bob C mailto:bob.c.f...@intel.com>>; Rodriguez, Christian mailto:christian.rodrig...@intel.com>>; Laszlo Ersek mailto:ler...@redhat.com>>; Kinney, Michael D mailto:michael.d.kin...@intel.com>>; Gao, Liming mailto:liming@intel.com>>; Shi, Steven mailto:steven@intel.com>>; Fan, ZhijuX mailto:zhijux@intel.com>> Subject: Re: [edk2-devel] Edk2 BaseTools Patches. On May 30, 2019, at 2:31 PM, Johnson, Michael mailto:michael.john...@intel.com>> wrote: All, These patches are not required for the stable tag. They’re improvements needed to enable relatively new build options that are not yet widely used. That said, let me try to clear the air here about what is happening regarding the sources/includes and what changes with these patches. The INF spec (section 3.9<https://edk2-docs.gitbooks.io/edk-ii-inf-specification/content/v/release/1.27/3_edk_ii_inf_file_format/39_%5bsources%5d_sections.html>) says that all local source files, including .h files, must be included in the sources section. This means a module is not compliant if it i
Re: [edk2-devel] Edk2 BaseTools Patches.
Andrew, What about the force include of AutoGen.h? AutoGen.h (and .c) have contents which are determined by various metadata like PCD values or items listed in the INF. The sources and dependencies can’t be involved, since those aren’t known until after the autogen files are already complete. The build calls genc before genmake. The hash accounts for those by incorporating the metadata itself, rather than the autogenerated files. If there is a rule the tools should enforce the rule with good error messages. For the case of the build hash feature, we have an EdkLogger.warn in these patches. Invalidating the hash allows the build to continue with up-to-date modules by sending the module back to the regular build process, and the message informs the user of what we found. Since the point of the feature is to speed up builds, I think this is right. If we instead stopped the build, when without --hash it would’ve completed successfully, then we’ve made a more restricted build that’s less useful, rather than giving the existing functionality a speed boost via caching. I’m not against broadening the use of this check to regular builds, but that has unanswered questions and its outside the scope of the BZs targeted by these patches. Do we want to check for this condition on every build and log when we see it? Do we want an optional build flag for it? Should another flag cause a halt and give an error, maybe something like “--strict” which could check for other spec violating conditions as well? It turns into a whole feature of its own, with considerably higher impact since *many* codebases in the wild have non-compliant modules sprinkled throughout. I think Leif and I are both concerned about having two ways to do something as complex as make dependencies, as they risk getting out of phase, or breaking different ways (like following the .h rules in the INF File). I understand the concern. One positive thing about the overly broad nature of hashing all possible legal includes and all compiler flags and all etc etc is that we don’t need to carry much understanding or complexity. We just hash ‘all the inputs’ and don’t bother looking any deeper. Further, when the hash of a module changes, it drops back to the regular path and the ordinary build/skip decision is made exactly as it would be in a regular build. I think this is simple enough to not be (too) troubling. At some point refactoring the build system from the top might be the right approach. Agreed. The build tools are critical and could use more attention. Maybe someday… -Michael From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io Sent: Thursday, May 30, 2019 3:53 PM To: devel@edk2.groups.io; Johnson, Michael Cc: Leif Lindholm ; Feng, Bob C ; Rodriguez, Christian ; Laszlo Ersek ; Kinney, Michael D ; Gao, Liming ; Shi, Steven ; Fan, ZhijuX Subject: Re: [edk2-devel] Edk2 BaseTools Patches. On May 30, 2019, at 2:31 PM, Johnson, Michael mailto:michael.john...@intel.com>> wrote: All, These patches are not required for the stable tag. They’re improvements needed to enable relatively new build options that are not yet widely used. That said, let me try to clear the air here about what is happening regarding the sources/includes and what changes with these patches. The INF spec (section 3.9<https://edk2-docs.gitbooks.io/edk-ii-inf-specification/content/v/release/1.27/3_edk_ii_inf_file_format/39_%5bsources%5d_sections.html>) says that all local source files, including .h files, must be included in the sources section. This means a module is not compliant if it includes a header file from a directory other than a package include directory and fails to list it in its sources section. We’re already generating a hash which is guaranteed to change whenever the module’s source changes - without invoking mkdep - by hashing each file from the sources section as well as *all* the contents of every include folder belonging to each package that the module is dependent on. Every possible ‘legally’ included header will change the hash, Michael, What about the force include of AutoGen.h? but the hashes of non-compliant modules will not change when their ‘illegally’ included headers change and we will incorrectly re-use stale cached binaries. To prevent this, the below patches check for compliance and invalidate the hash of any non-compliant module. In this way, non-compliance is neither supported nor allowed to poison the cache. If there is a rule the tools should enforce the rule with good error messages. Again, since this only has an effect on builds which have enabled this relatively new feature, I don’t expect any production impact if the stable tag doesn’t take these patches. Nobody is using it yet. I think Leif and I are both concerned about having two ways to do something as complex as make dependencies, as they risk
Re: [edk2-devel] Edk2 BaseTools Patches.
> On May 30, 2019, at 2:31 PM, Johnson, Michael > wrote: > > All, > > These patches are not required for the stable tag. They’re improvements > needed to enable relatively new build options that are not yet widely used. > > That said, let me try to clear the air here about what is happening regarding > the sources/includes and what changes with these patches. > > The INF spec (section 3.9 > <https://edk2-docs.gitbooks.io/edk-ii-inf-specification/content/v/release/1.27/3_edk_ii_inf_file_format/39_%5bsources%5d_sections.html>) > says that all local source files, including .h files, must be included in > the sources section. This means a module is not compliant if it includes a > header file from a directory other than a package include directory and fails > to list it in its sources section. We’re already generating a hash which is > guaranteed to change whenever the module’s source changes - without invoking > mkdep - by hashing each file from the sources section as well as *all* the > contents of every include folder belonging to each package that the module is > dependent on. > > Every possible ‘legally’ included header will change the hash, Michael, What about the force include of AutoGen.h? > but the hashes of non-compliant modules will not change when their > ‘illegally’ included headers change and we will incorrectly re-use stale > cached binaries. To prevent this, the below patches check for compliance and > invalidate the hash of any non-compliant module. In this way, non-compliance > is neither supported nor allowed to poison the cache. > If there is a rule the tools should enforce the rule with good error messages. > Again, since this only has an effect on builds which have enabled this > relatively new feature, I don’t expect any production impact if the stable > tag doesn’t take these patches. Nobody is using it yet. > I think Leif and I are both concerned about having two ways to do something as complex as make dependencies, as they risk getting out of phase, or breaking different ways (like following the .h rules in the INF File). Also I understand some times we hit circular dependencies and that forces duplication. It would be good in general to try and make a list of these kind of circular dependencies, given they may been caused by a faulty high level design decision made long ago. At some point refactoring the build system from the top might be the right approach. Thanks, Andrew Fish > -Michael > > <> > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behalf Of > Andrew Fish via Groups.Io > Sent: Thursday, May 30, 2019 11:10 AM > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; Leif Lindholm > mailto:leif.lindh...@linaro.org>> > Cc: Feng, Bob C mailto:bob.c.f...@intel.com>>; > Rodriguez, Christian <mailto:christian.rodrig...@intel.com>>; Laszlo Ersek <mailto:ler...@redhat.com>>; Kinney, Michael D <mailto:michael.d.kin...@intel.com>>; Gao, Liming <mailto:liming@intel.com>>; Shi, Steven <mailto:steven@intel.com>>; Fan, ZhijuX <mailto:zhijux@intel.com>> > Subject: Re: [edk2-devel] Edk2 BaseTools Patches. > > > > > On May 30, 2019, at 9:37 AM, Leif Lindholm <mailto:leif.lindh...@linaro.org>> wrote: > > Thanks Bob, Christian, > > On Thu, May 30, 2019 at 03:06:48PM +, Feng, Bob C wrote: > > Thanks Christian. I add some short description for the patches. > > These 5 patches are all for binary cache feature. > > [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources > section > [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file > > The above 2 patches is to fix the issue that > The build tool uses the files list under [sources] section of INF > file as a input to calculate a module's hash value. But in some INF > files, [sources] does not list all the "source" files, missing some > .h files. Path 2/2 use another method to get all source files for a > module and patch 1/2 do a check whether [sources] list all the > "source" files. > > I'll be honest - because of the wild variance in whether .h files are > listed in the [sources] section of .inf files, I have always been > unsure as to whether they were just being ignored (and extracted on > the side via mkdep or similar). > > > Leif, > > I'm confused too as you can only really know the set of include files by > doing the mkdep? > > I don't see the value of hashing the local include files as any include file > change in the mkdep path requires the module to be rec
Re: [edk2-devel] Edk2 BaseTools Patches.
All, These patches are not required for the stable tag. They're improvements needed to enable relatively new build options that are not yet widely used. That said, let me try to clear the air here about what is happening regarding the sources/includes and what changes with these patches. The INF spec (section 3.9<https://edk2-docs.gitbooks.io/edk-ii-inf-specification/content/v/release/1.27/3_edk_ii_inf_file_format/39_%5bsources%5d_sections.html>) says that all local source files, including .h files, must be included in the sources section. This means a module is not compliant if it includes a header file from a directory other than a package include directory and fails to list it in its sources section. We're already generating a hash which is guaranteed to change whenever the module's source changes - without invoking mkdep - by hashing each file from the sources section as well as *all* the contents of every include folder belonging to each package that the module is dependent on. Every possible 'legally' included header will change the hash, but the hashes of non-compliant modules will not change when their 'illegally' included headers change and we will incorrectly re-use stale cached binaries. To prevent this, the below patches check for compliance and invalidate the hash of any non-compliant module. In this way, non-compliance is neither supported nor allowed to poison the cache. Again, since this only has an effect on builds which have enabled this relatively new feature, I don't expect any production impact if the stable tag doesn't take these patches. Nobody is using it yet. -Michael From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io Sent: Thursday, May 30, 2019 11:10 AM To: devel@edk2.groups.io; Leif Lindholm Cc: Feng, Bob C ; Rodriguez, Christian ; Laszlo Ersek ; Kinney, Michael D ; Gao, Liming ; Shi, Steven ; Fan, ZhijuX Subject: Re: [edk2-devel] Edk2 BaseTools Patches. On May 30, 2019, at 9:37 AM, Leif Lindholm mailto:leif.lindh...@linaro.org>> wrote: Thanks Bob, Christian, On Thu, May 30, 2019 at 03:06:48PM +, Feng, Bob C wrote: Thanks Christian. I add some short description for the patches. These 5 patches are all for binary cache feature. [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources section [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file The above 2 patches is to fix the issue that The build tool uses the files list under [sources] section of INF file as a input to calculate a module's hash value. But in some INF files, [sources] does not list all the "source" files, missing some .h files. Path 2/2 use another method to get all source files for a module and patch 1/2 do a check whether [sources] list all the "source" files. I'll be honest - because of the wild variance in whether .h files are listed in the [sources] section of .inf files, I have always been unsure as to whether they were just being ignored (and extracted on the side via mkdep or similar). Leif, I'm confused too as you can only really know the set of include files by doing the mkdep? I don't see the value of hashing the local include files as any include file change in the mkdep path requires the module to be recompiled. It seems to me having one scheme for hashing and anther four building is going to cause a lot of very subtle errors that are really hard to debug. When you have these kind of errors in your build system you teach people they always need to make clean, so they bypass the hashing and dependency checks. Seems like we may be fighting the makefiles again, but from a 10,000 point of view it seems like the dependency algorithm and the hash need to be tied together. Seems like the makefile already knows if it needs to build it, but I'm not sure if the makefile can run an action if it does not need to build something? Thanks, Andrew Fish If the intent is to speed up build time, would it not be better to warn the user - so they notice the problem and fix their modules, rather than adding extra processing time on having the tools work with broken .inf files? This does not look like material for edk2-stable201905 to me. [PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache This patch is to resolve the problem that Build tool dose not cache the library binaries now. Whiteout this patch, there is 25% extra time cost to rebuild the all module dependency libraries if cache miss happen. 25% is a big number, so I won't argue against this. But I also won't argue for it - the BZ was raised very late in the cycle. [PATCH] BaseTools:Update binary cache restore time to current time This patch is to make the restored binary file have the current time stamp not the binary file original time stamp. I can see how the current behaviour could cause problems with some CI/build systems. If it is prope
Re: [edk2-devel] Edk2 BaseTools Patches.
> On May 30, 2019, at 9:37 AM, Leif Lindholm wrote:
>
> Thanks Bob, Christian,
>
> On Thu, May 30, 2019 at 03:06:48PM +, Feng, Bob C wrote:
>> Thanks Christian. I add some short description for the patches.
>>
>> These 5 patches are all for binary cache feature.
>>
>> [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources
>> section
>> [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file
>>
>> The above 2 patches is to fix the issue that
>> The build tool uses the files list under [sources] section of INF
>> file as a input to calculate a module's hash value. But in some INF
>> files, [sources] does not list all the "source" files, missing some
>> .h files. Path 2/2 use another method to get all source files for a
>> module and patch 1/2 do a check whether [sources] list all the
>> "source" files.
>
> I'll be honest - because of the wild variance in whether .h files are
> listed in the [sources] section of .inf files, I have always been
> unsure as to whether they were just being ignored (and extracted on
> the side via mkdep or similar).
>
Leif,
I'm confused too as you can only really know the set of include files by doing
the mkdep?
I don't see the value of hashing the local include files as any include file
change in the mkdep path requires the module to be recompiled. It seems to me
having one scheme for hashing and anther four building is going to cause a lot
of very subtle errors that are really hard to debug. When you have these kind
of errors in your build system you teach people they always need to make clean,
so they bypass the hashing and dependency checks.
Seems like we may be fighting the makefiles again, but from a 10,000 point of
view it seems like the dependency algorithm and the hash need to be tied
together. Seems like the makefile already knows if it needs to build it, but
I'm not sure if the makefile can run an action if it does not need to build
something?
Thanks,
Andrew Fish
> If the intent is to speed up build time, would it not be better to
> warn the user - so they notice the problem and fix their modules,
> rather than adding extra processing time on having the tools work with
> broken .inf files?
>
> This does not look like material for edk2-stable201905 to me.
>
>> [PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache
>> This patch is to resolve the problem that
>> Build tool dose not cache the library binaries now. Whiteout this
>> patch, there is 25% extra time cost to rebuild the all module
>> dependency libraries if cache miss happen.
>
> 25% is a big number, so I won't argue against this. But I also won't
> argue for it - the BZ was raised very late in the cycle.
>
>> [PATCH] BaseTools:Update binary cache restore time to current time
>> This patch is to make the restored binary file have the current time
>> stamp not the binary file original time stamp.
>
> I can see how the current behaviour could cause problems with some
> CI/build systems. If it is properly reviewed and tested, I am OK with
> this one going in for edk2-stable201903.
>
>> [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS
>> FILE
>> This patch is to support the raw ffs file rule. Now build tool does
>> not correctly handle this case:
>>
>> [Rule.Common.USER_DEFINED.MicroCode]
>> FILE RAW = $(NAMED_GUID) {
>> $(INF_OUTPUT)/$(MODULE_NAME).bin
>> }
>
> This looks like a new feature - not something that should bypass the
> freeze period for edk2-stable201905.
> Can you explain why this is needed in the stable tag as opposed to
> being available from master the day after the tag is made?
>
> Best Regards,
>
> Leif
>
>>
>>
>> Thanks,
>> Bob
>>
>> -Original Message-
>> From: Rodriguez, Christian
>> Sent: Thursday, May 30, 2019 10:26 PM
>> To: Leif Lindholm ; Feng, Bob C
>>
>> Cc: Andrew Fish ; Laszlo Ersek ; Kinney,
>> Michael D ; devel@edk2.groups.io; Gao, Liming
>> ; Shi, Steven ; Fan, ZhijuX
>>
>> Subject: RE: Edk2 BaseTools Patches.
>>
>> Hey Leif,
>>
>> I thought I'd help Bob and gather those BZs for each thread:
>>
>> [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file
>> [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources
>> section
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1804
>>
>> [PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1797
>>
>> [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS
>> FILE
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1765
>>
>> [PATCH] BaseTools:Update binary cache restore time to current time
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1742
>>
>> Thanks,
>> Christian
>>
>>> -Original Message-
>>> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
>>> Sent: Thursday, May 30, 2019 2:28 AM
>>> To: Feng, Bob C
>>>
Re: [edk2-devel] Edk2 BaseTools Patches.
See below.
>-Original Message-
>From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
>Sent: Thursday, May 30, 2019 9:38 AM
>To: Feng, Bob C
>Cc: Rodriguez, Christian ; Andrew Fish
>; Laszlo Ersek ; Kinney, Michael D
>; devel@edk2.groups.io; Gao, Liming
>; Shi, Steven ; Fan, ZhijuX
>
>Subject: Re: Edk2 BaseTools Patches.
>
>Thanks Bob, Christian,
>
>On Thu, May 30, 2019 at 03:06:48PM +, Feng, Bob C wrote:
>> Thanks Christian. I add some short description for the patches.
>>
>> These 5 patches are all for binary cache feature.
>>
>> [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for
>> Sources section [Patch V4 1/2] BaseTools: Add a checking for Sources
>> section in INF file
>>
>> The above 2 patches is to fix the issue that The build tool uses the
>> files list under [sources] section of INF file as a input to calculate
>> a module's hash value. But in some INF files, [sources] does not list
>> all the "source" files, missing some .h files. Path 2/2 use another
>> method to get all source files for a module and patch 1/2 do a check
>> whether [sources] list all the "source" files.
>
>I'll be honest - because of the wild variance in whether .h files are listed
>in the
>[sources] section of .inf files, I have always been unsure as to whether they
>were just being ignored (and extracted on the side via mkdep or similar).
>
>If the intent is to speed up build time, would it not be better to warn the
>user
>- so they notice the problem and fix their modules, rather than adding extra
>processing time on having the tools work with broken .inf files?
>
>This does not look like material for edk2-stable201905 to me.
The patch does warn the user, so they notice the problem and fix their modules.
And somewhere in the email thread for that patch set I mentioned the processing
time is almost negligible since the information is already available in memory
and it's just a simple set lookup for existence and warning write.
It doesn't really matter if it goes in edk2-stable201905, as long as it goes in
eventually because it does fix a bug/corner-case in the hash feature.
>
>> [PATCH v3 1/1] BaseTools:Extend the binary cache to support library
>> cache This patch is to resolve the problem that Build tool dose not
>> cache the library binaries now. Whiteout this patch, there is 25%
>> extra time cost to rebuild the all module dependency libraries if
>> cache miss happen.
>
>25% is a big number, so I won't argue against this. But I also won't argue for
>it -
>the BZ was raised very late in the cycle.
>
>> [PATCH] BaseTools:Update binary cache restore time to current time
>> This patch is to make the restored binary file have the current time
>> stamp not the binary file original time stamp.
>
>I can see how the current behaviour could cause problems with some CI/build
>systems. If it is properly reviewed and tested, I am OK with this one going in
>for edk2-stable201903.
>
>> [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW
>> FFS FILE This patch is to support the raw ffs file rule. Now build
>> tool does not correctly handle this case:
>>
>> [Rule.Common.USER_DEFINED.MicroCode]
>> FILE RAW = $(NAMED_GUID) {
>> $(INF_OUTPUT)/$(MODULE_NAME).bin
>> }
>
>This looks like a new feature - not something that should bypass the freeze
>period for edk2-stable201905.
>Can you explain why this is needed in the stable tag as opposed to being
>available from master the day after the tag is made?
>
>Best Regards,
>
>Leif
>
>>
>>
>> Thanks,
>> Bob
>>
>> -Original Message-
>> From: Rodriguez, Christian
>> Sent: Thursday, May 30, 2019 10:26 PM
>> To: Leif Lindholm ; Feng, Bob C
>>
>> Cc: Andrew Fish ; Laszlo Ersek ;
>> Kinney, Michael D ; devel@edk2.groups.io;
>> Gao, Liming ; Shi, Steven
>> ; Fan, ZhijuX
>> Subject: RE: Edk2 BaseTools Patches.
>>
>> Hey Leif,
>>
>> I thought I'd help Bob and gather those BZs for each thread:
>>
>> [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF
>> file [Patch V4 2/2] BaseTools: Refactor hash tracking after checking
>> for Sources section
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1804
>>
>> [PATCH v3 1/1] BaseTools:Extend the binary cache to support library
>> cache
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1797
>>
>> [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW
>> FFS FILE
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1765
>>
>> [PATCH] BaseTools:Update binary cache restore time to current time
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1742
>>
>> Thanks,
>> Christian
>>
>> >-Original Message-
>> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
>> >Sent: Thursday, May 30, 2019 2:28 AM
>> >To: Feng, Bob C
>> >Cc: Andrew Fish ; Laszlo Ersek ;
>> >Kinney, Michael D ; devel@edk2.groups.io;
>> >Gao, Liming ; Shi, Steven
>> >; Rodriguez, Christian
>> >; Fan, ZhijuX
>> >Subject: Re: Edk2 BaseTools Patches.
>> >
>> >Hi
Re: [edk2-devel] Edk2 BaseTools Patches.
Thanks Bob, Christian,
On Thu, May 30, 2019 at 03:06:48PM +, Feng, Bob C wrote:
> Thanks Christian. I add some short description for the patches.
>
> These 5 patches are all for binary cache feature.
>
> [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources
> section
> [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file
>
> The above 2 patches is to fix the issue that
> The build tool uses the files list under [sources] section of INF
> file as a input to calculate a module's hash value. But in some INF
> files, [sources] does not list all the "source" files, missing some
> .h files. Path 2/2 use another method to get all source files for a
> module and patch 1/2 do a check whether [sources] list all the
> "source" files.
I'll be honest - because of the wild variance in whether .h files are
listed in the [sources] section of .inf files, I have always been
unsure as to whether they were just being ignored (and extracted on
the side via mkdep or similar).
If the intent is to speed up build time, would it not be better to
warn the user - so they notice the problem and fix their modules,
rather than adding extra processing time on having the tools work with
broken .inf files?
This does not look like material for edk2-stable201905 to me.
> [PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache
> This patch is to resolve the problem that
> Build tool dose not cache the library binaries now. Whiteout this
> patch, there is 25% extra time cost to rebuild the all module
> dependency libraries if cache miss happen.
25% is a big number, so I won't argue against this. But I also won't
argue for it - the BZ was raised very late in the cycle.
> [PATCH] BaseTools:Update binary cache restore time to current time
> This patch is to make the restored binary file have the current time
> stamp not the binary file original time stamp.
I can see how the current behaviour could cause problems with some
CI/build systems. If it is properly reviewed and tested, I am OK with
this one going in for edk2-stable201903.
> [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS FILE
> This patch is to support the raw ffs file rule. Now build tool does
> not correctly handle this case:
>
> [Rule.Common.USER_DEFINED.MicroCode]
> FILE RAW = $(NAMED_GUID) {
> $(INF_OUTPUT)/$(MODULE_NAME).bin
> }
This looks like a new feature - not something that should bypass the
freeze period for edk2-stable201905.
Can you explain why this is needed in the stable tag as opposed to
being available from master the day after the tag is made?
Best Regards,
Leif
>
>
> Thanks,
> Bob
>
> -Original Message-
> From: Rodriguez, Christian
> Sent: Thursday, May 30, 2019 10:26 PM
> To: Leif Lindholm ; Feng, Bob C
>
> Cc: Andrew Fish ; Laszlo Ersek ; Kinney,
> Michael D ; devel@edk2.groups.io; Gao, Liming
> ; Shi, Steven ; Fan, ZhijuX
>
> Subject: RE: Edk2 BaseTools Patches.
>
> Hey Leif,
>
> I thought I'd help Bob and gather those BZs for each thread:
>
> [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file
> [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources
> section
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1804
>
> [PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1797
>
> [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS FILE
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1765
>
> [PATCH] BaseTools:Update binary cache restore time to current time
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1742
>
> Thanks,
> Christian
>
> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: Thursday, May 30, 2019 2:28 AM
> >To: Feng, Bob C
> >Cc: Andrew Fish ; Laszlo Ersek ;
> >Kinney, Michael D ; devel@edk2.groups.io;
> >Gao, Liming ; Shi, Steven ;
> >Rodriguez, Christian ; Fan, ZhijuX
> >
> >Subject: Re: Edk2 BaseTools Patches.
> >
> >Hi Bob,
> >
> >On Thu, May 30, 2019 at 06:39:59AM +, Feng, Bob C wrote:
> >> Hi,
> >>
> >> Currently, we have 5 Basetools patches which are ready to push. Since
> >> we are in the soft-freeze phase, I'd like to ask for your opinions if
> >> those patches can be pushed to edk2 master.
> >
> >To save me the time of reading through all the threads and getting to
> >grips with all the code, could you summarise the problem these solve
> >and the impact of not including these?
> >
> >Is there a BZ?
> >
> >Regards,
> >
> >Leif
> >
> >>
> >> These 5 patches are to fix the issues for the build cache feature.
> >>
> >> [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for
> >> Sources section
> >> https://edk2.groups.io/g/devel/topic/31835556#41642
> >>
> >> [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF
> >> file
> >>
Re: [edk2-devel] Edk2 BaseTools Patches.
Thanks Christian. I add some short description for the patches.
These 5 patches are all for binary cache feature.
[Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources
section
[Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file
The above 2 patches is to fix the issue that
The build tool uses the files list under [sources] section of INF file as a
input to calculate a module's hash value. But in some INF files, [sources] does
not list all the "source" files, missing some .h files. Path 2/2 use another
method to get all source files for a module and patch 1/2 do a check whether
[sources] list all the "source" files.
[PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache
This patch is to resolve the problem that
Build tool dose not cache the library binaries now. Whiteout this patch, there
is 25% extra time cost to rebuild the all module dependency libraries if cache
miss happen.
[PATCH] BaseTools:Update binary cache restore time to current time
This patch is to make the restored binary file have the current time stamp not
the binary file original time stamp.
[PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS FILE
This patch is to support the raw ffs file rule. Now build tool does not
correctly handle this case:
[Rule.Common.USER_DEFINED.MicroCode]
FILE RAW = $(NAMED_GUID) {
$(INF_OUTPUT)/$(MODULE_NAME).bin
}
Thanks,
Bob
-Original Message-
From: Rodriguez, Christian
Sent: Thursday, May 30, 2019 10:26 PM
To: Leif Lindholm ; Feng, Bob C
Cc: Andrew Fish ; Laszlo Ersek ; Kinney,
Michael D ; devel@edk2.groups.io; Gao, Liming
; Shi, Steven ; Fan, ZhijuX
Subject: RE: Edk2 BaseTools Patches.
Hey Leif,
I thought I'd help Bob and gather those BZs for each thread:
[Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file [Patch
V4 2/2] BaseTools: Refactor hash tracking after checking for Sources section
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1804
[PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1797
[PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS FILE
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1765
[PATCH] BaseTools:Update binary cache restore time to current time
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1742
Thanks,
Christian
>-Original Message-
>From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
>Sent: Thursday, May 30, 2019 2:28 AM
>To: Feng, Bob C
>Cc: Andrew Fish ; Laszlo Ersek ;
>Kinney, Michael D ; devel@edk2.groups.io;
>Gao, Liming ; Shi, Steven ;
>Rodriguez, Christian ; Fan, ZhijuX
>
>Subject: Re: Edk2 BaseTools Patches.
>
>Hi Bob,
>
>On Thu, May 30, 2019 at 06:39:59AM +, Feng, Bob C wrote:
>> Hi,
>>
>> Currently, we have 5 Basetools patches which are ready to push. Since
>> we are in the soft-freeze phase, I'd like to ask for your opinions if
>> those patches can be pushed to edk2 master.
>
>To save me the time of reading through all the threads and getting to
>grips with all the code, could you summarise the problem these solve
>and the impact of not including these?
>
>Is there a BZ?
>
>Regards,
>
>Leif
>
>>
>> These 5 patches are to fix the issues for the build cache feature.
>>
>> [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for
>> Sources section
>> https://edk2.groups.io/g/devel/topic/31835556#41642
>>
>> [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF
>> file
>> https://edk2.groups.io/g/devel/topic/3183#41641
>>
>> [PATCH v3 1/1] BaseTools:Extend the binary cache to support library
>> cache
>> https://edk2.groups.io/g/devel/topic/31843505#41655
>>
>> [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW
>> FFS FILE
>> https://edk2.groups.io/g/devel/topic/31830807#41571
>>
>> [PATCH] BaseTools:Update binary cache restore time to current time
>> https://edk2.groups.io/g/devel/topic/31819590#41468
>>
>>
>> Thanks,
>> Bob
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#41677): https://edk2.groups.io/g/devel/message/41677
Mute This Topic: https://groups.io/mt/31866190/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Edk2 BaseTools Patches.
Hey Leif, I thought I'd help Bob and gather those BZs for each thread: [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources section BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1804 [PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1797 [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS FILE BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1765 [PATCH] BaseTools:Update binary cache restore time to current time BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1742 Thanks, Christian >-Original Message- >From: Leif Lindholm [mailto:leif.lindh...@linaro.org] >Sent: Thursday, May 30, 2019 2:28 AM >To: Feng, Bob C >Cc: Andrew Fish ; Laszlo Ersek ; >Kinney, Michael D ; devel@edk2.groups.io; >Gao, Liming ; Shi, Steven ; >Rodriguez, Christian ; Fan, ZhijuX > >Subject: Re: Edk2 BaseTools Patches. > >Hi Bob, > >On Thu, May 30, 2019 at 06:39:59AM +, Feng, Bob C wrote: >> Hi, >> >> Currently, we have 5 Basetools patches which are ready to push. Since >> we are in the soft-freeze phase, I'd like to ask for your opinions if >> those patches can be pushed to edk2 master. > >To save me the time of reading through all the threads and getting to grips >with all the code, could you summarise the problem these solve and the >impact of not including these? > >Is there a BZ? > >Regards, > >Leif > >> >> These 5 patches are to fix the issues for the build cache feature. >> >> [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for >> Sources section >> https://edk2.groups.io/g/devel/topic/31835556#41642 >> >> [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF >> file >> https://edk2.groups.io/g/devel/topic/3183#41641 >> >> [PATCH v3 1/1] BaseTools:Extend the binary cache to support library >> cache >> https://edk2.groups.io/g/devel/topic/31843505#41655 >> >> [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW >> FFS FILE >> https://edk2.groups.io/g/devel/topic/31830807#41571 >> >> [PATCH] BaseTools:Update binary cache restore time to current time >> https://edk2.groups.io/g/devel/topic/31819590#41468 >> >> >> Thanks, >> Bob -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41675): https://edk2.groups.io/g/devel/message/41675 Mute This Topic: https://groups.io/mt/31866190/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Edk2 BaseTools Patches.
Hi Bob, On Thu, May 30, 2019 at 06:39:59AM +, Feng, Bob C wrote: > Hi, > > Currently, we have 5 Basetools patches which are ready to > push. Since we are in the soft-freeze phase, I'd like to ask for > your opinions if those patches can be pushed to edk2 master. To save me the time of reading through all the threads and getting to grips with all the code, could you summarise the problem these solve and the impact of not including these? Is there a BZ? Regards, Leif > > These 5 patches are to fix the issues for the build cache feature. > > [Patch V4 2/2] BaseTools: Refactor hash tracking after checking for Sources > section > https://edk2.groups.io/g/devel/topic/31835556#41642 > > [Patch V4 1/2] BaseTools: Add a checking for Sources section in INF file > https://edk2.groups.io/g/devel/topic/3183#41641 > > [PATCH v3 1/1] BaseTools:Extend the binary cache to support library cache > https://edk2.groups.io/g/devel/topic/31843505#41655 > > [PATCH V5] BaseTools:Make BaseTools support new rules to generate RAW FFS FILE > https://edk2.groups.io/g/devel/topic/31830807#41571 > > [PATCH] BaseTools:Update binary cache restore time to current time > https://edk2.groups.io/g/devel/topic/31819590#41468 > > > Thanks, > Bob -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#41672): https://edk2.groups.io/g/devel/message/41672 Mute This Topic: https://groups.io/mt/31866190/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
