Re: [PATCH] More accessible usage of custom flags

[Nicholas Marquez]

On Sat, Feb 23, 2008 at 6:39 PM, Nick Andrew <nick@xxxxxxxxxxxxxxx> wrote:
> On Sat, Feb 23, 2008 at 05:28:23PM -0500, Nicholas Marquez wrote:
>  > First of all, thanks for the input!
>  >
>  > On Sat, Feb 23, 2008 at 5:04 PM, Nick Andrew <nick@xxxxxxxxxxxxxxx> wrote:
>  > > On Sat, Feb 23, 2008 at 04:28:50PM -0500, Nicholas Marquez wrote:
>  >
>
> > There are a few places in the Makefile where options would need to be
>  > entered.  This just brings those places together in a clean manner and
>  > allows for one to set the flags via the configuration interface.
>  > Though it would be excellent if the kernel had more gcc
>  > micro-optimization (facilitated by such features as the upcoming gcc
>  > 4.3's -finstrument-functions-exclude-function-list option), general
>  > CFLAGS used for the entire kernel do not impact the safety of the
>  > kernel build, assuming that the options are sane.  It would be
>  > interesting, however, to see an initiative to tune gcc flags for
>  > important functions and  sections within the kernel for optimal
>  > performance given some sort of envisioned usage.  (*hint, kernel devs,
>  > hint*)
>
>  If there are some "common" optimisation flags or sets of flags then
>  maybe they could be turned on/off by invididual config options? There's
>  already CC_OPTIMIZE_FOR_SIZE sorta tagged as experimental. But then,
>  enumerating the allowable flags may limit the user's choices whereas I
>  take it you'd like to expand them.

Yes, I would like to expand them.  If possibly, I'd like to take out
the individual config options for gcc flags and integrate them into
the help description.  I feel that the redundancy would not only be
ugly, but possibly confusing.
- Show quoted text -


>
>
>  > >  > >  @@ -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.
>  > >
>  > >  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.
>  >
>  > Sorry about that.  I didn't mean to portray it as "shouting" so much
>  > as a very visible and stern warning.
>
>  I'm hoping we don't need any stern warnings in the kernel configuration.
>  Although I expect configuring bogus gcc flags is going to break the
>  build far worse than selecting bad options otherwise. If the user
>  makes a mistake in CUSTOM_CFLAGS is the build going to fail with
>  a message "error in CUSTOM_CFLAGS" or is it going to spew out pages
>  of gcc error messages?  It is nice if error messages can point back
>  to the source of the error, so the user doesn't have to look through
>  the entire kernel configuration for what they did wrong.

I hadn't thought of that.  It would certainly be more useful than a
stern warning.  ^^;  Have you any ideas on how to implement such a
thing?  I would imagine a configure-script-like test on the flags to
make sure that gcc could take them correctly would be in order.  Then
one could also capture any warnings or errors that gcc outputs (such
as redundant flags, improper invocation, etc.), fail the build, and
output the messages.  As far as capturing dangerous flags for the
kernel (such as -ffast-math or -fmerge-all-constants), there could be
a blacklist... but that would depend on the gcc version used... :/
Perhaps the automated catching of errors and warnings would be best
alone.
>
>
>  > Something else that could be included is a link to the manual for the
>  > (currently used) gcc's command flags
>  > (http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/index.html#toc_Invoking-GCC)
>  > or at least to the online docs, considering that specifying one
>  > specific gcc version's manual would yield various issues.
>
>  "info gcc" will give all that information in far more detail than I
>  have time to read.

I believe you misunderstand.  I mean to include the link in the help
message.  Like how the links to the appropriate sites for device
drivers are included in their help messages.
>
>
>  > >  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.
>  >
>  > I feel that perhaps it is a bit silly to put in such description, as
>  > one using the flags should only do so in knowing specifically which
>  > ones they wish to use and why ahead of time.  However, it cannot hurt
>  > to put in more help documentation, so it's a fine suggestion.
>
>  Well, it can't be both silly and a fine suggestion. Does it dumb down
>  the kernel configuration process too much?

No, I feel that both adjectives are perfectly reconcilable, at least
in this case.  Again, more documentation couldn't hurt.  "Dumbing
down" kernel configuration may be less aesthetically pleasing to
purists, but that is a tiny price to pay for usability and a widening
of kernel builders.

>
>  I don't want a single person to say "I can't configure this kernel
>  because I don't know what to answer for the CUSTOM_CFLAGS question"
>  and I think the "If unsure, leave blank" at the bottom covers that
>  problem. But I assume you want to encourage experimentation; there
>  will be a person with a bit higher level of skill who might want
>  to start tweaking. Here's something they can start tweaking.
>
>

Safe experimentation, yes.  So I agree with you that adding various
statements in the help message can only do good.  Sorry for the
confusion.
- Hide quoted text -

>
>  Nick.
>  --
>  PGP Key ID = 0x418487E7                      http://www.nick-andrew.net/
>  PGP Key fingerprint = B3ED 6894 8E49 1770 C24A  67E3 6266 6EB9 4184 87E7
>

PS to Nick:  Sorry for the double-send. Didn't CC lkml;  a forward
would be ugly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/