On 12/14/2013 12:36 AM, ron minnich wrote:
And I think it even worse to put the microcode blobs in a location in the tree that implies, by its existence, that you can build without them and get a more free, working firmware image.
You can't have a working build on a bunch of recent hardware without blobs. So the assumption that you can build without blobs is false. Pure and simple.
On Fri, Dec 13, 2013 at 10:46 PM, mrnuke mr.nuke.me@gmail.com wrote:
You can't have a working build on a bunch of recent hardware without blobs. So the assumption that you can build without blobs is false. Pure and simple.
ok, so you are upset that "clueless" (your word, not mine :-) people complain about blobs, and in response you move a bunch of .h files from one place to another? With no real change, mind you, since they still have to use them. Nothing is more 'free'.
What's the point? Why not just enlighten them? I just can not understand this.
Again, the intent of the blobs directory was to be a place into which to fetch binary blobs, for those things we could not include in the main tree. The microcode .h files don't fit that category, given that they are already in the tree. So I still don't see a point to all this extra effort.
Anyway, if you can convince me I'm happy to remove the -2 but I'm not yet convinced.
ron
On 14.12.2013 07:46, mrnuke wrote:
On 12/14/2013 12:36 AM, ron minnich wrote:
And I think it even worse to put the microcode blobs in a location in the tree that implies, by its existence, that you can build without them and get a more free, working firmware image.
You can't have a working build on a bunch of recent hardware without blobs. So the assumption that you can build without blobs is false. Pure and simple.
What about making it explicit and forbid builds without blobs repo on cpus which have microcode update? The forbidding part would be just one line per CPU and those whi remove it modify source, so they take responsibility for themselves if something goes wrong. I'm not fan of running without microcode update and I agree with you in most points. I see advantage in maintainance by using separate repo for thing under different license but since I'm not the one doing most of the maintainance it's purely decision of those who do (do-o-cracy).
-
mrnuke -
ron minnich -
Vladimir 'φ-coder/phcoder' Serbinenko