On 03/21/2014 05:28 PM, ron minnich wrote:
On Fri, Mar 21, 2014 at 1:33 PM, mrnuke mr.nuke.me@gmail.com wrote:
On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote:
Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :(
Is there any way whatsoever to temporarily use the cache as SRAM?
when we did the first real CAR work MTRRs were not needed. I'm not sure if they would be on the vortex. We might want to test the very early CAR code and see how it goes. It's actually quite simple.
It would be nice to make sure modern hardware uses modern infrastructure.
Also, let's just take it a little easy here. These are proposals, nothing is ever perfect on first release, the world is not ending, Google is not showing up at coreboot.org in skimasks and unmarked uniforms ...
Damn! I was hoping to steal some ski gear from them.
I think a fork would harm everyone
Sure, if you stab the person hard enough.
and would be destructive of our common goals. Please remember that we are all trying to do the right thing, and our different situations give us different perspectives.
When Stefan sounds so serious, it's hard to tell whether he is just proposing, or announcing changes. Remember, he's the guy that can port a new board with his eyes closed [1]. People take him too seriously sometimes.
Nobody is coming in here with bad motives. We're just trying to muddle our way through the many demands of different stakeholders now that coreboot, thanks to the efforts of some pretty dedicated people, has become a runaway success.
The bad-ness or good-ness of motives is relative. Note that I'm not using "bad" in the sense of "evil". Let's look at the six gatekeeper idea: * Easier for commercial entities to upstream code, therefore faster progress for coreboot (good motive). (a) * Easier for commercial entities to upstream code, therefore we can get lazy even if code quality drops (bad motive). (b)
So, in your 15 years of doing this, which option should prevail?
Alex
On Fri, Mar 21, 2014 at 6:52 PM, Alex G. mr.nuke.me@gmail.com wrote:
The bad-ness or good-ness of motives is relative. Note that I'm not using "bad" in the sense of "evil". Let's look at the six gatekeeper idea:
- Easier for commercial entities to upstream code, therefore faster
progress for coreboot (good motive). (a)
- Easier for commercial entities to upstream code, therefore we can get
lazy even if code quality drops (bad motive). (b)
That's not the intent. The way you are stating this has a lot of built-in assumptions, and you're mixing some things up. That's our fault; the old rule is, that if someone did not understand what you said, it's your fault, not theirs. So, speaking as one of the guys who reviewed the email, I'm sorry it was not clearer.
So, first, the intent of the six gatekeeper idea is, in part, to be sure we're being very careful about what goes in. We've had some cases over the past 2-3 years where some inexperienced guys pushed 'commit' on code that broke a bunch of boards -- in ways that were not obvious. We would like to avoid that. As we've learned the hard way a few times, there are not that many people who have the perspective of long experience and a view of all the boards, and know how trivial changes can have far-reaching consequences.
Now, can this be serious? Yes, very serious. There was a laptop (no names mentioned here, ok?) I know of in which the vendor made a trivial several line change which caused memory corruption on resume. It shipped. The BIOS was baked in; the recovery had to be implemented in the OS. That kind of thing is not fun. But now that coreboot has succeeded in such a big way, trivial changes can have very serious consequences, and we need to be more careful than 15 years ago when it was just us hackers. This is in part why I'm not generally happy with unifying code -- because trivial changes can have unforeseen consequences, and in the past one of the pain points has been well-intentioned code unification ideas that resulted in propagating bugs from one chipset to another.
As for "easier upstreaming for commerical guys", again, your summary is wide of the mark -- again, not your fault. The review process has gotten a bit tricky, for the simple reason that the same guys that can +2 reviews to the chromeos coreboot repo end up having to do it twice for the upstream. It's a consequence of the fact that the commercial guys have to build coreboot for a product and end up having to develop code they can't upstream immediately. Can we skip the whole discussion of why this is necessary, btw? It is.
Coreboot has succeeded. Many people that are authoring coreboot code also work at companies now -- kind of like what's happened with Linux. It's not something we had to deal with 3 years ago.
But it makes no sense for, e.g., Duncan Laurie to have to +2 Aaron Durbin's very fine code twice. First off, these two guys have full time jobs (well, 2, really, packed into one, they work hard), they write some of the best code that goes into the repo, and at least from my point of view, a +2 from either of them is usually good enough for me (that also applies to lots of people outside, btw; when I see +1 or +2 from a lot of you folks, I know the review is going to be easier than if I start from nothing. Some of you would be surprised how much I depend on what you write, even when I complain about some of your commit messages :-). Plus, the internal review process on the chromeos coreboot repo is extremely rigorous (and annoying at times).
So it's not about "Easier for commercial entities to upstream code" -- it's about not having to do the full review process *twice*, given that the code has been picked to pieces by experienced long-time coreboot coders, most of whom (no offense intended) are better qualified to review the code than almost anyone else. That's why I claim what you are saying as not quite right.
Finally, a simple question here: how many gatekeepers are there for the final full released version of each version of the Linux kernel?
My $.02 anyway.
ron
-
Alex G. -
ron minnich