Julius Werner wrote:
Having an undocumented (or silently installed, therefore unexpected) dependency is undesirable (especially for a firmware), no question about that.
Sorry, I still get the impression that there is a fundamental misunderstanding about what Git submodules are here.
I know how submodules work, I believe Nico too. I also know the internal git data model very well.
For me this isn't really a matter of automation or trust but simply one of avoiding complexity where it isn't mandated.
It's source code that comes cryptographically guaranteed
Sure, but more source code and in particular across more repositories is a lot more complexity than less source code in a single repository.
I appreciate that my concern, if pointedly articulated, was considered and found to be valid. I don't believe that it's very complex to find a good solution, but you can maybe understand that I think it unfair that you invite me to provide the remedy for a problem that I didn't create.
Let's see how it goes.
the Git SHA of the submodule HEAD is stored in the main coreboot repo.
My argument is solely on complexity, but please don't trust that hash too much.
No, I don't think most people submitting to cbfstool are somehow applying some magic unwritten portability standard that vboot is lacking to be honest.
The lower common denominator one targets the more effort is required, and different contributors are likely to trade off differently here, I think we've all seen corporate contributions favor raw development speed over everything else in many projects and I guess coreboot has this happen too from time to time.
And if they do, and you can tell me what it is, we are happy to apply the same standard to vboot going forward.
I think that's a fantastic promise! I also understand and agree with your request for standardization/documentation, something to set expectations, that's 100% reasonable.
I don't think "just write it fully portable" is a reasonable goal since clearly we need __attributes__ like ((packed)),
I disagree about packed - I think the argument for (de)serialization is quite strong - but I understand that this may not be universal, and it trades development effort for portability.
libgfxinit
I think that's a fair point as well - that has also tripped me up - but it's been less severe for me than the hard vboot requirement.
So I really don't think vboot deserves the award for most cumbersome submodule right now.
I can't say that it is - only that it's bothered me for a while.
I'm happy that there's an outlook at least, but obviously I'd rather not have to fix a problem I didn't cause. Let's see.
Thanks everyone so far
//Peter