LKML Archive on
help / color / mirror / Atom feed
From: Nick Andrew <>
To: Nicholas Marquez <>
Subject: Re: [PATCH] More accessible usage of custom flags
Date: Sun, 24 Feb 2008 09:04:58 +1100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sat, Feb 23, 2008 at 04:28:50PM -0500, Nicholas Marquez wrote:
> 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.

I missed it the first time you posted it, so thanks for resending.

> On Sat, Feb 16, 2008 at 9:52 PM, Nicholas Marquez
> <> 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.

Does using this patch reduce the safety of the kernel build at all? i.e.
is it more likely to build different parts of the kernel with
incompatible options with this patch, compared to if the options were
specified in the Makefile?

> >  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'm currently cleaning up the Kconfig help descriptions to try to help
the second group of people. Also I think there's a spectrum of
capabilities involved. I'd like kernel building to be a fun and useful
activity for a wider group of people :-)

> >  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.

Heh, that includes me too.

> >  ______
> >  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

I've just started using StGit and it makes it a lot easier to make, send
and manage patches. You should take a look at it.

> >  @@ -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).
> >  +
> >  +
> >  +        If unsure, leave blank.

Sorry, but I don't think we need shouting. There are a few options
already which have bad results if you unknowingly choose the wrong option,
like enabling EMBEDDED and turning off the BLOCK layer, yet the help
description doesn't shout.

Can I suggest:

	  You can use this to easily set custom gcc CFLAGS to be used
	  for the entire kernel build process (including modules).

	  Compiler flags can be used for increasing or reducing
	  optimisation, enabling debugging, cross compilation
	  and so on.

	  If unsure, leave blank.

The boilerplate "If unsure, leave blank" covers (or is meant to cover)
the situation where the user does not know what they are doing. It says
"If you don't know what you are doing, just leave this field blank,
and everything will be OK" ... except it is put in a non-threatening,
non-demeaning way.

The paragraph in the middle enhances the "help" component of the help
description, by saying why you might want to use that option.

> >  +config CUSTOM_LDFLAGS
> >  [...]
> >  +config CUSTOM_AFLAGS
> >  [...]
> >  [...]

Similar comments apply.

PGP Key ID = 0x418487E7            
PGP Key fingerprint = B3ED 6894 8E49 1770 C24A  67E3 6266 6EB9 4184 87E7

  reply	other threads:[~2008-02-23 22:06 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
2008-02-23 22:04   ` Nick Andrew [this message]
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:

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

  git send-email \ \ \ \ \
    --subject='Re: [PATCH] More accessible usage of custom flags' \

* 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).