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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
