Recommended way to patch source code

[jdoubleu]

Hi, I‘m looking for an elegant way to patch source files in the EDK2 repo for my project.

I need to slightly change the code of some libraries e.g. in the MdePkg. So far I‘ve applied these patches on top of a fork of the repo, that I maintain. However that makes updating the EDK2 and maintaining my fork harder.

Unfortunately there is no way to influence (neither patch nor add additional) the source files of a Module (.inf) in my Platform (.dsc). For EDK1, I learned, there was a <SOURCE_OVERRIDE_DIR> mechanism.

What’s the recommended way to maintain custom patches?

[ajfish]

On Jan 7, 2026, at 7:52 AM, jdoubleu ***@***.***> wrote: Hi, I‘m looking for an elegant way to patch source files in the EDK2 repo for my project. I need to slightly change the code of some libraries e.g. in the MdePkg. So far I‘ve applied these patches on top of a fork of the repo, that I maintain. However that makes updating the EDK2 and maintaining my fork harder. Unfortunately there is no way to influence (neither patch nor add additional) the source files of a Module (.inf) in my Platform (.dsc). For EDK1, I learned, there was a <SOURCE_OVERRIDE_DIR> mechanism. What’s the recommended way to maintain custom patches?

I think the primary answer is don’t use the MdePkg library class and make a new library class that has a new API that does what you want. So add a library header and instance to your package and call your new API to get different behavior. If that does not work for you it might be worth while to ask “What Are You Trying to Do” on the mailing list as maybe you are trying to implement something the wrong way? If you are trying to add additional behavior to existing libs (logging, profiling, etc) just fork the libraries to a new package and maintain a new instance of the libraries. Then have your DSC point at your forked library vs. MdePkg instance. This does not work if you are overriding something in MdeLibs.dsc.inc [1] (assuming you are including that). But otherwise in your DSC [LibraryClasses] you just change: PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf To: PcdLib|MyPkg/Library/BasePcdLibNull/BasePcdLibNull.inf Then in general the original fork is from a known version and you know your patch applied. The down side is you have to apple patches by hand going forward. [1] https://github.com/tianocore/edk2/blob/master/MdePkg/MdeLibs.dsc.inc Thanks, Andrew Fish

…

— Reply to this email directly, view it on GitHub <#11971>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4ZCO3LDELJ7IQ32PZ34ZD4FUTSNAVCNFSM6AAAAACQ6YLUFOVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGMYTQNJVGI>. You are receiving this because you are subscribed to this thread.

[jdoubleu]

Thanks for the quick response!

Sure forking the entire library and changing it to my needs seems like a straightforward way to keep these patches off the EDK2 repo. However it doesn't really solve the issue with maintainability, in the worst case it makes it even harder.

I've found a better example: I need to extend OpenSSL. By default only a few selected algorithms are enabled. Adding additional algorithms, usually involves:

1. Add a source file (.c) from the OpenSSL git submodule to CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf.
2. Enabling/Registering the new algorithm in OpensslStub/uefiprov.c

Forking the entire OpensslLibCrypto in this case seems a bit overblow.

In other I cases I just need to change a few lines in existing Libraries, changing a pattern or a version number, for example.