LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Nicholas Marquez" <nicholas.marquez@gatech.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] More accessible usage of custom flags
Date: Sat, 23 Feb 2008 16:28:50 -0500	[thread overview]
Message-ID: <e367bd3e0802231328l1eb928f5pe538264c3a42e3d2@mail.gmail.com> (raw)
In-Reply-To: <e367bd3e0802161852v1265f101h86326b16362dd860@mail.gmail.com>

Does anyone else have any input on this?  Tips, suggestions, ideas,
comments, constructive criticism, anything at all.  I am, however,
trying to avoid a flame war.

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

On Sat, Feb 16, 2008 at 9:52 PM, Nicholas Marquez
<nicholas.marquez@gatech.edu> wrote:
> 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@gatech.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
>

  parent reply	other threads:[~2008-02-23 21:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-17  2:52 Nicholas Marquez
2008-02-17 10:37 ` Alexey Dobriyan
2008-02-17 16:34   ` Nicholas Marquez
2008-02-23 21:28 ` Nicholas Marquez [this message]
2008-02-23 22:04   ` Nick Andrew
2008-02-23 22:28     ` Nicholas Marquez
2008-02-23 23:39       ` Nick Andrew
2008-02-24  9:36         ` Nicholas Marquez
2008-02-24 12:50           ` Nick Andrew
2008-02-24 20:00             ` Nicholas Marquez
2008-02-28 19:45 ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e367bd3e0802231328l1eb928f5pe538264c3a42e3d2@mail.gmail.com \
    --to=nicholas.marquez@gatech.edu \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH] More accessible usage of custom flags' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).