On Fri, Aug 19, 2016 at 01:23:31PM +0200, Ard Biesheuvel wrote:
At which point I'm quite OK with the "importing", as long as it's wrapped into something that does not require components accessing it to have special knowledge of its internal typedefs and macros.
But I'd also be astonished if David Miller accepted the MV_UINT32 type defines.
If there isn't a common upstream for this driver between projects, then they will diverge and whichever ends up with more devs will be the source of patches and hence their code style will be de facto standard. Plus we won't be able to merge GPL licensed contributions anyway, so we can't really be a downstream of the Linux driver.
So in that case, yes, I would prefer EDK2-ising it. But I'd appreciate Ard's input. Either way, we should start by isolating the typedefs and macros into a separate header forming part of 1/3.
I think we should be pragmatic about importing existing code. I care very little about things like STATIC, VOID, and CONST, since they are unconditionally #defined to static, void and const, respectively, anyway.
Sure, but that's the lesser problem here.
Also, checkpatch scripts are useful for spotting changes that result in coding style violations in files that were formerly compliant. Taking existing code and then perform blanket search/replace on them for things like the above is a waste of effort imo, especially if there are other changes required that may actually affect code size or correctness in UEFI context, like alignment or struct assignment, things that are forbidden for a reason. If such changes are needed, I would like to see them in a separate patch that goes on top of the original introduction of the new code.
Right, but I'm not obsessing over what the initial commit should look like, I'm obsessing over what the resulting code should look like.
We cannot have the consumers of said imported patches needing to redefine a bunch of datatypes in order to call them. But also, if we are not expecting to be seeing some sort of destination-independent updates to this driver from the vendor, I see little value in keeping the code non-compliant.
/ Leif