-
Notifications
You must be signed in to change notification settings - Fork 286
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
Native UEFI shim #235
Native UEFI shim #235
Conversation
This was auto-closed because I can't re-assign it to rhboot:main and for some reason it didn't follow when the default branch was renamed. @rusnikola can you please edit this to make it be against rhboot:main and re-open it? That said, I think other developers had some significant misgivings about this approach - mostly that edk2's build system is terrible - but I don't want to lose track of it. |
@vathpela thanks for letting me know. btw, edk2 is not that bad if you just use their headers only but not Makefiles, etc :) What happened to the "master" branch and those experimental changes (e.g., edk2)? Is it just completely abandoned? |
"devel" is the old master, and I'm working on backporting and merging to a new main while some other development happens. If using the edk2 submodule from devel makes it easier, do it against that - either is fine with me. |
@vathpela yes, I already relocated my last version several months ago for the old master (which is now "devel"). So basically my version should already work on top of devel (including devel's edk2 module). Should I just update the pull request for devel or is it going to be abandoned eventually (e.g., the edk2 module going to be abandoned, etc) So, in other words, will you have edk2 in the "main" repo eventually? If so, probably it makes sense for me to keep it for devel for now and when those changes will be committed to main, I can relocate my version as well. |
Updated my fork (which generates true PE/COFF images) to the most recent version. Since edk2 headers are also adopted by the original shim now, code changes are reduced. Latest clang/llvm (with required flags) are already in common Linux distributions. Would it make sense to consider those changes for upstreaming? It is also possible to provide it as an additional option (in case if gcc compatibility is desired).