On Wed, Nov 20, 2013 at 07:42:44PM +0100, Martin Sperl wrote: > One argument for explicitly naming what IS fixed, is the fact that > this way the default 0 maps to the current behavior, where you may not > make any "assumptions".
Sure, but then this only applies if the client explicitly calls a function to optimise things. Anything done transparently behind clients should definitely set all the flags but things that are actively engaging with optimisation are different and it's that I'm thinking about here. Otherwise what happens is that if we add a new variable (like we did when we added support for dual and quad mode recently) we end up having to go round every client driver updating them to say that this new thing they never heard of isn't going to change which doesn't seem like winning. > I right now started to build a kernel from your sources, but it compiles > slowly on a raspberry-pi... (also the default .config is not complete and > a lot of things are left outside, like can support as module,... - I wish > someone would maintain a better .config I could use instead of starting > with make bcm2835_defconfig) Cross building FTW :) If you can't test anyway then build testing on x86 is fine.
signature.asc
Description: Digital signature
