On 02/26/2011 10:19 PM, xdrudis wrote:
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.
I look at the microcode as simply DIP switches used to configure the IRQ line on the hardware. If the manual (microcode updates) gives me erroneous information, then I put the switches back to their initial position (factory microcode). You will disagree and say that, as long as it can be updated, and source code exists for it, it is software, not hardware.
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.
How about something simple, such as
Unselect this option if you do not wish coreboot to update the CPU microcode, or if you experience issues arising from updating the microcode.
Note that microcode updates are designed to fix issues and bugs in the CPU. Also most operating systems will update the automatically, so you may still end up running with an updated microcode.
You may, at your option, select to disable microcode updating if you believe it to be in violation with your views on software freedom.
If unsure, select y.
This is accurate to the best of my knowleddge.
But since Stefan didn't like "IANAL", I bet he won't like this either.
IANAL, while a fact, is irrelevant in a help menu. Your profession, or mine for that reason, has no relevance in the context of deciding whether or not to disallow microcode updates.
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".
We want coreboot to be practical. The "maybe" can fill up a text file larger than the coreboot source. We don't care. If disabling microcode updates works for you, that is sufficient reason to consider this option
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.
And yet we still do update the microcode for the majority of users, and we even ship it to you when you download the coreboot source. There is practicality arising from thought alone, only giving you the choice to exire from the complications the rest of us subject ourselves to, if any.
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.
It almost an unwritten law ,not just in coreboot, but in anythat ones first patch will not get accepted without at least a revision. It is a thoughtless initiation rite, an unconscious demonstration of power and masculinity from those veteran enough to afford it. It is also a way to ensure succession over generations: to get you thinking more deeply about the code you modified, to understand it better, to inescapably see it in your dreams, so that when you wake up, you will improve it more, all in an attempt to get YOU to continue contributing. It is an instinct of survival.
I'm not one of the core developers. I'm just a vigilante patching a broken society. I'm actually incredibly virgin to the project, only having joined last month. I get put through the same treatment, and I do not find offense in it. I am not told that my work is broken, but _why_. This _why_ is the only way to advance the ranks to the point of ensuring heredity to the project. Whether I will continue to chase lawless criminals, invest countless sleepless hours, and abstain from basic nutrition in the desire to aquire the hardware necessary to do so, is unbeknownst to me. And I do not care. I make the best of the time I spend _now_ .
Shortening the server-kneeling spree of characters, you should not quit because of points of view differing, or the mud getting too deep. You should only quit if you feel you lost interest, or rather, if you stop feeling any interest. Whether you are laying down your arms from exhaustion or your country has more appealing issues at hand, only you can decide.
Alex