On Tue, May 22, 2018 at 2:25 PM, Youness Alaoui <kakar...@kakaroto.homelinux.net> wrote: > On Fri, May 18, 2018 at 2:59 PM, Nico Huber <nic...@gmx.de> wrote: >> >> I have to admit, I don't like your patch. While it gets the job done, >> it brings `MemInfoHob.h` and `FspsUpd.h` out of sync, so the state in >> coreboot as a whole would match neither version. >> > Good point. It is a Frankenstein, but it was either that or have > #ifdefs in the fsp vendorcode itself to determine if attribute X is > available or not, etc.. > >>> - or abandon my patch (which means I can never send a working >>> board-status for the librems without having a dirty tree or a version >>> commit hash that doesn't match upstream) >>> - or have the possibility to choose between the two (either via >>> #ifdefs or via a variants method). >> >> If we can't get a new, fitting binary out of Intel, I would prefer this, >> or, more bluntly, just copy the GitHub version and revert the changes >> that need the additional UPD. >> >> In other words, whatever happens, I think we should have the headers >> of the latest public release in the tree. >> > > I agree, that's probably the cleanest solution, but I didn't suggest > it because I figured people would be yelling about removing > functionality that might need to be re-added eventually if Intel end > up doing an updated release. > >>> - or, if Intel people are reading this right now (or someone here can >>> poke them directly), have the public release updated so this matter >>> can be dropped entirely (the public update would need to be released >>> *very* soon though). >> >> Even if you (Purism) poke them about it, that might help. But I would >> like to see that Google does that too (IMHO, they profit most from the >> mess). Any of you should have more leverage than the customer of a >> customer of a customer of a potential customer of Intel has, that I >> work for ;) > I know no-one at Intel to poke them about. I'll ask if Todd has > contacts that might be able to help. I'm hoping that some of the > people that are working for Intel are following this email thread but > if they are, they haven't raised their hands. Anyone knows or can > suggest the name of someone that we might poke ? I'm guessing those > working for Google who actually received the newer FSP from Intel > might know who to ask, and since they are the ones that would be > affected by their code/features being removed if we revert to github > version of header, it might help put some pressure on this issue (so > far, I haven't seen any incentive to make them do that).
I thought I said something somewhere -- maybe on a code review? Anyway, I've been pushing on this from my end. I don't have an answer yet, though. > >> >>> Should we put this to a vote now, or should we discuss the >>> possibilities/alternatives some more, if anyone has ideas on how to >>> tackle this specific issue ? >> >> Well, my vote, in order of preference: >> >> 1. Poke Intel. >> 2. Get a verbatim copy of the GitHub headers in (in a way of [least] effort >> for >> the community). Maybe in a month from now? no matter the outcome >> from 1. >> >> Nico > > I agree, and I give my 100% vote for that as well. It will be much > better than an #ifdef mess and would be a good incentive for the > people from Intel not saying "no, too much hassle to update the file, > we got nothing to lose anyway if we just ignore this". > So let's see who can poke who from Intel, let's give a deadline (1 or > 2 months? if bureaucracy means it will take longer, we might revisit > if we at least got a confirmation that the issue is being looked at on > Intel's side), then once deadline is reached, we revert to public > headers and remove functionality that prevents building (access to > nonexistent fields in UPD) and in the future, reject patches on gerrit > for non public blobs. > > Thanks! -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot