Message-ID: <e367bd3e0802161852v1265f101h86326b16362dd860@mail.gmail.com>
Date:	Sat, 16 Feb 2008 21:52:51 -0500
From:	"Nicholas Marquez" <nicholas.marquez@...ech.edu>
To:	linux-kernel@...r.kernel.org
Cc:	akpm@...l.org
Subject: [PATCH] More accessible usage of custom flags

I submitted this patch to the zen-sources Gentoo community and got
much praise and has promptly been included.  This kind of thing have
very likely already been done in other patchsets, but I haven't seen
it around, so I've gone ahead and made one.  The idea is that one can
enable -Os and various other options transparently through standard
kernel configuration, so why bar the builder from any other options to
pass on to gcc (et al)?  One can indeed add one's own flags in the
Makefile, but this method is a good deal friendlier.  Granted, this
could be misused by ricers and idiots, but they'll get themselves into
that mess all of their own fault and we'll all go on our merry ways.
It just seems that much use could be made out of this, both in terms
of (sane) optimizations and easier access to enhanced debugging
opportunities.

I see that people who build a Linux kernel are largely of two types:
~the ones that understand and know enough that they could, with some
nudging and learning, become bonafide kernel devs and
~the ones that understand it to some very basic degree and can get
through configuring it without too much trouble (though with limited
understanding)
I believe one of the very simple things that can be addressed is to
make the kernel more "accessible" without harming its integrity or
functionality.  This involves trying to fill the gap between those two
types of people, allowing there to be more understanding,
configuration, and (down the line) development opportunities within
the kernel to better ease these people into learning enough to begin
contributing back.  More developers can only be a Good Thing (tm).
Though a haughty and abstract opinion/goal/thought of mine, this patch
conforms to it and I think that with minimal effort such a vision
could be implemented.  Whilst all other kernel devs are hacking away
at the rough and tumultuous innards of the kernel, a few people of
less confidence and experience (people like me) could polish the
outside to make it more appealing to more people. So that eventually
they too will sink below the surface and join the party.

Anyway, I'm not quite sure that my implementation is as clean as it
could be and any feedback is certainly welcome.  This is my first time
posting to LKML, so I fully expect to be shot down anyway.


~Nicholas (Alex) Marquez
<nicholas.marquez@...ech.edu>

______
diff -dur original/init/Kconfig modified/init/Kconfig
--- original/init/Kconfig    2008-02-16 20:24:22.000000000 -0500
+++ modified/init/Kconfig    2008-02-16 20:53:48.000000000 -0500
@@ -487,6 +487,52 @@
       option.  If problems are observed, a gcc upgrade may be needed.

       If unsure, say N.
+
+menu "Custom flags"
+
+config CUSTOM_CFLAGS
+    string "Custom CFLAGS for kernel"
+    default ""
+    help
+        You can use this to easily set custom gcc CFLAGS to be used for the
+        entire kernel (including modules).
+
+        ONLY ADD CUSTOM CFLAGS IF YOU KNOW WHAT YOU ARE DOING
+
+        If unsure, leave blank.
+
+config CUSTOM_LDFLAGS
+    string "Custom LDFLAGS for kernel"
+    default ""
+    help
+        You can use this to easily set custom gcc LDFLAGS to be used for the
+        entire kernel (including modules).
+
+        ONLY ADD CUSTOM LDFLAGS IF YOU KNOW WHAT YOU ARE DOING
+
+        If unsure, leave blank.
+
+config CUSTOM_AFLAGS
+    string "Custom AFLAGS for kernel"
+    default ""
+    help
+        You can use this to easily set custom gcc AFLAGS to be used for the
+        entire kernel (including modules).
+
+        ONLY ADD CUSTOM AFLAGS IF YOU KNOW WHAT YOU ARE DOING
+
+        If unsure, leave blank.
+
+config CUSTOM_MAKEFLAGS
+    string "Custom MAKEFLAGS for kernel"
+    default ""
+    help
+        You can use this to easily set custom MAKEFLAGS to be used for building
+        the entire kernel.
+
+        If unsure, leave blank.
+
+endmenu

 config SYSCTL
     bool
diff -dur original/Makefile modified/Makefile
--- original/Makefile    2008-02-16 20:15:58.000000000 -0500
+++ modified/Makefile    2008-02-16 20:35:55.000000000 -0500
@@ -14,7 +14,7 @@
 # o  use make's built-in rules and variables
 #    (this increases performance and avoids hard-to-debug behaviour);
 # o  print "Entering directory ...";
-MAKEFLAGS += -rR --no-print-directory
+MAKEFLAGS += -rR --no-print-directory $(CUSTOM_MAKEFLAGS)

 # We are using a recursive build, so we need to do a little thinking
 # to get the ordering right.
@@ -315,11 +315,11 @@

 CHECKFLAGS     := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__
-Wbitwise $(CF)
 MODFLAGS    = -DMODULE
-CFLAGS_MODULE   = $(MODFLAGS)
-AFLAGS_MODULE   = $(MODFLAGS)
-LDFLAGS_MODULE  =
-CFLAGS_KERNEL    =
-AFLAGS_KERNEL    =
+CFLAGS_MODULE   = $(MODFLAGS) $(CUSTOM_CFLAGS)
+AFLAGS_MODULE   = $(MODFLAGS) $(CUSTOM_AFLAGS)
+LDFLAGS_MODULE  = $(CUSTOM_LDFLAGS)
+CFLAGS_KERNEL    = $(CUSTOM_CFLAGS)
+AFLAGS_KERNEL    = $(CUSTOM_AFLAGS)


 # Use LINUXINCLUDE when you must reference the include/ directory.
@@ -525,6 +525,10 @@
 KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
 endif

+# Apply custom flags
+KBUILD_CFLAGS    += $(CUSTOM_CFLAGS)
+KBUILD_AFLAGS    += $(CUSTOM_AFLAGS)
+
 # Force gcc to behave correct even for buggy distributions
 KBUILD_CFLAGS         += $(call cc-option, -fno-stack-protector)

@@ -560,7 +564,7 @@
 LDFLAGS_BUILD_ID = $(patsubst -Wl$(comma)%,%,\
                   $(call ld-option, -Wl$(comma)--build-id,))
 LDFLAGS_MODULE += $(LDFLAGS_BUILD_ID)
-LDFLAGS_vmlinux += $(LDFLAGS_BUILD_ID)
+LDFLAGS_vmlinux += $(LDFLAGS_BUILD_ID) $(CUSTOM_LDFLAGS)

 # Default kernel image to build when no specific target is given.
 # KBUILD_IMAGE may be overruled on the command line or
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists