On Thu, Aug 18, 2016 at 04:21:28PM +0200, Ard Biesheuvel wrote:
I appreciate that this is some external piece of code being imported, but I would like to see some statement as to the plans for how to deal with this in future:
Are we expecting to update these two files frequently directly from new vendor releases?
- If so, should we deal with this more like the way EDK2 deals with OpenSSL? (have a look in CryptoPkg/Library/OpensslLib/)
- If not, could we convert this driver to something that would be acceptable in an EDK2 tree without any special treatment?
Unless you're happy to do the latter, I would actually be quite keen to move this discussion to edk2-devel to ensure we don't encure unexpected extra effort at a future migration of OpenPlatformPkg code into an official Tianocore repository.
Do you think that following solution is acceptable - leave 'import patch' as is and add 'adjust to edk2 style' on top of it?
So how are we going to track upstream changes to this library?
Well, the question is - should/are we going to be tracking upstream changes to this library? If not, I'd rather not have added files that will keep triggering PatchCheck errors on every future modification. If we are, I would much prefer us to 'import' this library before build, like we do with OpenSSL. Yes, there is a huge difference in scale, but the situation is similar.
In fact, if there is a public upstream that carries this code, I'd like the git commit hash of the version that we imported in the commit log of this patch.
+1
/ Leif