On 02/27/2011 12:46 AM, xdrudis wrote:
On Sat, Feb 26, 2011 at 11:22:17PM +0200, Alex G. wrote:
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.
Let's leave this aside. If it was a picture of something nice instead of microcode you would still have legal complications depending on the license. When you include a work in another you create a derivative work and need permission from the copyright holders of both. No one asks you what the works are (ok, yes, they do, but that's for details).
No, I'm not leaving it aside. The microcode you wish to disable (and IIRC you, Peter, Stepan, and I agree to providing this choice via an elegant Kconfig option) was provided by AMD, and they have given us permission to use it in our code, with our license. In fact, they provided the (coreboot) patches themselves. The developers provided permission for the microcode to be used with coreboot, by committing it.
You can translate that to ethical terms about using the work of others respecting their conditions if you wish.
And I just detailed how this applies here.
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.Shouldn't we tell something about how to tell an issue arises from updating the microcode? I can't. Other than trying to disable it.
We should, but at the moment, we don't have enough information. It's a try before you buy issue.
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.Good
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.
I think it misses three facts:
- the issues arising from the microcode updates have been observed (are not hypothetical). But this is not giving much information either.
I would argue that "if you experience issues arising from updating the microcode" implies someone has already hit this, but alright, let's change it to:
Unselect this option if you do not wish coreboot to update the CPU microcode. Some persons have experienced problems with updating the microcode that were solved when the update was disabled. If you believe you may be experiencing an issue related to updating the microcode, unselect this option. There is currently little information available on the effects of this.
- the license of the microcode patches is not free (how can you believe
it to be in violation of freedom if you're not told this?)
Third paragraph leaves you, the user, to decide this. We are not the FSF, we cannot decide for others.
- coreboot does not include all microcode updates ever produced by the
manufacturer (my intention is to be fair if some issue is not due to something in the microcode patch but to misapplication by coreboot or lack of fresher updates).
Are you expecting coreboot to include them all?
But I don't care. I can accept your text. It's an expert option, shouldn't need a perfect help.
Of course you're not. It's an expert option. If you tackle with this menu, you already know it tries to include the latest microcode available, not all of them, right?
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.
If one reason is legal complications, and who says it is not a lawyer, it's relevant. I think the objections where more about : there's no "I" in a Kconfig file that can be lawyer or not, and uncertainity is to be avoided because it has an unprofessional look and is perceived as complicating usage .
And that is exactly what I meant.
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
Certainly. I wasn't pretending to put that text in the help, only explaining why I couldn't put anything useful.
The text was the only objection I had, and I hoped we were working to improve it
And yet we still do update the microcode for the majority of users,
This has ethical consequences but might be made legally simpler by reading microcode patches from external files.
Agreed entirely, but as you claim to be lazy and only do it for Fam10 CPUs, so de we, and do not write the infrastructure code to support this.
and we even ship it to you when you download the coreboot source.
in the source it is more an agregation that a derived work. It's compiling that makes the derived work. Or maybe I'm confused.
As trunk stands at the moment of this writing, coreboot cannot be compiled without the microcode, and thus you may very well argue it is a derived work. Your patch tries to change that, and we agree it is the better direction.
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.
I didn't understand, sorry.
I meant that I, as a user who compiles with the microcode, expose myself to the legal issues of including bytecode in a GPL work. You can choose not to do so by disabling the microcode update.
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
I hope no patch is accepted without a revision, first or otherwise. This is not exclusive of coreboot, and it is good policy.
It is a fact of life, not a policy. We do not artificially, or at least consciously try to make things hard for newcomers.
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
Right, I'm not interested in refining this patch further [nor in power, masculinity, initiation rites, survival by programming firmware or many other things].
I respect your choice.
It's also nice to quit when you feel you cannot offer anything useful. We only live so long.
You have already given us something of extreme value: the impulse to start considering this issue, the chance to discuss this. You have given us an idea, which is worth more than a thousand patches. Ideas can exist without patches, but not the other way around.
I wish you good luck in whatever you may choose to do next, and I want you to know that we will still be here (hopefully with an open mind) should you ever need our help. :)
All the best, Alex