David Hendricks wrote:
I suspect it's best to simply accept the ugly parts rather than diverge from whatever AMD uses internally.
I think it depends. If the coreboot repo is basically a write-once medium for the AMD code and if what gets written never has any reuse anyway then I think it would be fine to do cleanup.
ron minnich wrote:
Unless you're prepared to test and verify on the exact hardware, don't do it.
I agree with this. Testing is important after any major change.
I don't think it matters if we have life more complicated than the kernel, this particular cleanup effort would be quite isolated and can take place in some separate branch maintained by Paul or someone else.
It's not a high priority, but I do think it would be nice to have.
If at some point there is a perfectly clear branch with some simple commits that unify syntactical differences then that can be trivially reviewed by a larger group, and also easily tested and merged if there are no problems. This is of course the same model as for all other development, except I think a branch is warranted since it's a string of commits which do different logical changes but very much belong together, so I'd prefer to merge them all at once.
The kernel is not a guide for firmware work.
This is true, but a good structure is nothing unique to either kernel or firmware work - it's just basic good programming.
That said - I think that this particular construction site is not so important, and I would much rather like to see effort spent on some of "our own" construction sites in the code.
One example is to streamline code (or just files) across mainboard directories, or any one of the numerous worthwhile http://www.coreboot.org/Infrastructure_Projects
//Peter
-
Peter Stuge