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
