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