On Sat, Feb 26, 2011 at 04:01:56AM +0200, Alex G. wrote:
On 02/26/2011 03:38 AM, xdrudis wrote:
This is the patch for option B.
You may not be able to test it without my next patch. At least for me selectiong EXPERT in make menuconfig breaks the build. Next patch fixes it.
I don't like the wording for the help option.
Stefan Reinauer didn't like it either and I'm not sure he does now. I got no suggestions (alternative wordings) so I changed only the particulars he pointed to. Feel free to improve it.
[note: this pretty much summarised the other 120 lines, in case you don't read it all]
It creates the impression that the entire reason for this option is purely philosophical.
Not having the source, documentation and specific expertise is a philosophical problem but not only a philosophical problem. One of the consequences is that I can not give any satisfactory practical reasons for updating or not updating microcode. All I could write would be
Select this to apply non-free patches to the cpu microcode provided by AMD to correct issues in the CPU after production, and distributed with coreboot (not necessarily the latest microcode version produced by AMD, but only applied if newer than the version in your CPU).
The microcode patches are selected from mainboard Kconfig AMD_UCODE_PATCH_FILE among the src/cpu/amd/model_10xxx/mc_*.h files provided by AMD. We don't know the issues solved by each microcode patch file, the issues created by each file (possibly solved in other patches present in or absent from coreboot) or the preconditions to apply them to your particular CPU or to the set of CPUs the image you're configuring may run on. We know the intent of the patches is to solve issues and that we've had systems running well with the patches and issues also solved by not applying them.
Unselect to let FAM10 CPUs run with the unpatched microcode as shipped from factory. If you unselect this, no binary microcode patches will be included in the image, so it will help you get an image which you have the entire source code for and may simplify license compliance.
But since Stefan didn't like "IANAL", I bet he won't like this either. And maybe others here know more than what I just wrote, or it's published somewhere, it's just that for philosophical reasons, and the practical reason that it seems to work without updating microcode for me, I'm not interested in investigating the microcode details, and I suspect as much of Ivaylo. Maybe Ivaylo and I picked the wrong mc*.h file, maybe the right one isn't there, maybe the checks before the microcode update are somehow wrong, maybe our CPU is newer than the mc*.h files and it somehow fools the checks, maybe it's just wrong to have AMD_UCODE_PATCH_FILE as a mainboard option, and a rutime check should select, for each processor, beetwen all microcode patches available, so that a coreboot image could run on any CPU revision you can put on that board and socket. But I can't get past "maybe".
I accepted your argument for this option because you quoted practical reasons, such as the updated microcode causing problems, and thus I would prefer a help text focusing on those reasons.
The practical reasons are that not updating microcode is a shortcut through a few unknowns, and it may work better or worse than updating it (certainly better for me an Ivaylo, but I don't write the help for us). Since it has been previously stated that kconfig help shouldn't be qualified with uncertainity valuations but just express correct facts to the best of our knowledge, I'm unable to express the practical reasons without hinting at uncertain facts.
The only certain facts are that in some cases it works better without updating and in some (many?) others it works updating. I think too that in some cases it doesn't work without updating, but I don't have a concrete case to show (no fool has tried?). I fail to see how saying this can help. It could maybe help to specify the details of when it works updating or when it works not updating, but since I don't have source, documentation or expertise, I cannot guess what are the circumstances that cause it, I could only give every complete setup for each collection of cases, which seems too detailed and verbose. Should I say ASUS M4A77TD-PRO with Phenom X4 910e or rev RB_C3 in SVI or DDR3 with AM3 ?
That is not to say to avoid the philosophical issue altogether, but not invoke it as the main reason.
I think you overestimate the philosophical nature of practical reasons such as a simpler license compliance or working with a source backed code base. Of course they carry philosophical questions of no small importance and even epistemological questions here noted, but less legal trouble and less unknowns are practical reasons as well.
Other than that, pretty good job :)
Thank you.
I hope Stefan and Peter agree with you, because I don't. For me it looks uglier each time.
In fact this is starting to feel like design by committee. I think I'm doing something without further researching some parts because I'm not interested, and, although I wouldn't have bothered the list without practical reasons, I'm more motivated for legal peace of mind and software freedom than for the practical reasons, so I'm relunctant to hide it or to attribute it to practical reasons. And you (and possibly others) are trying to accept a new option because you want to be nice, sympathise with some general philosophy, and are concerned with accomodating all use cases but you think it will hardly ever work so you want it hidden, explained and with warnings.
In a way we both stand in a quasi contradictory position each and are trying to reconcile these different positions. If I liked this sort of bargaining I'd send a resumé to the European Council. I'm all for peer review (no offense intended calling you my peers) and throwing more eyeballs at things, and discussing stuff until we're all convinced, but I've run out of time and motivation, and i don't really find I have much more to offer.
If anyone wants to take it from here you can refine and commit one of these patches (option A or B), or come up with something new, but it will take someone more aligned with the general sentiment than myself, to really code something that makes sense to herself and later can be made acceptable to all. So I'll leave it here.
Thanks to all for your attention and sorry for not being able of more.