On Thu, Oct 24, 2013 at 9:18 PM, Adam Carter <adamcart...@gmail.com> wrote: > > To build with other flags you set CFLAGS_KERNEL, so i've added a suitable > -march to the standard ones for my system; > export CFLAGS_KERNEL=" -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 > -fomit-frame-pointer -pipe -march=amdfam10" > > then make, install, reboot. In my case the riced kernel is the same size as > the regular one, but the md5 is different. Its been up for an hour with no > obvious issues, and does seem snappier, but of course my brain is full of > cognitive bias. Has anyone else played with this? Any good or bad outcomes? > </original email>
FWIW, have found that some kernel module ebuilds fail to pick these hacks up, if you are using them, and, indeed, (erroneously?) respect {C,XXFLAGS}. An example that comes to mind is vmware-modules. I have a script that extracts the CFLAGS from the Makefile and then exports them and invokes modules-rebuild or whatever the correct name of that is.... not really anything I'd like to share, it's a pretty embarrassingly ugly script with lots of system-specific crud... been meaning to clean it up one of these days for general consumption. Anyhow, whether you rice your kernel in this way or not, that is something to think about. In general, I am pretty uncomfortable messing with the kernel CFLAGS. You might want to ask yourself: do I really have a complete understanding of how my riced CFLAGS might affect things like state pickling during kernel context switching? Non-standard points in the code-base such as early boot, when it might not be safe to assume that the kernel is not in some crazy intermediate state with respect to memory layout, exception handling, etc.? Will my flags create function invocation ABI incompatibilities that require corresponding changes in kernel assembler code? After digging into it just a little, I pretty much came to the conclusion, persnally, that I didn't have clear answers to those questions and that it wasn't worth the risk of creating (even more) buggy kernels. Is there macro magic that might break? I decided, for myself, against any such kernel-cflag rice, but I do have hardware RAID with dead battery backup batteries (which I perpetually never get around to replacing) ... makes crashing my kernel pretty damn expensive, and I try only to do it in emulators, if at all possible (far too often, I crash them anyhow). You might have a much more crash-friendly environment or have spare hardware lying around that you can experiment with in a consequence-free environment. Not saying don't go for it... but my advice would be, basically, think carefully before you frob unless you're OK with the idea of running a potentially extra-buggy kernel. -- gmt