Date:	Sun, 17 Feb 2008 11:34:42 -0500
From:	"Nicholas Marquez" <nicholas.marquez@...ech.edu>
To:	"Alexey Dobriyan" <adobriyan@...il.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...l.org
Subject: Re: [PATCH] More accessible usage of custom flags

On Feb 17, 2008 5:37 AM, Alexey Dobriyan <adobriyan@...il.com> wrote:
> On Sat, Feb 16, 2008 at 09:52:51PM -0500, 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,
>
> Probably it wasn't done by other patchsets. ;-)
>
> > 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)?
>
> Examples, please. Which compiler flags do you want to add to your .config?
> Speaking of -Os, it's CONFIG_CC_OPTIMIZE_FOR_SIZE .

For example: DFORTIFY_SOURCE=2 or ftree-ch, because it's not enabled
by Os, but does indeed help often, especially in the case of various
kernel codepaths.
As to CONFIG_CC_OPTIMIZE_FOR_SIZE, I realize.  "-Os" is just easier to
type and I assume that a kernel dev list would map the correct config
option.  ;)

>
> > 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.
>
> No, they will come here and report bugs they created themselves. And
> there will be a policy: "too long CONFIG_CUSTOM_CFLAGS -- go away" and
> so on.

My point exactly.  Enabling experimental or broken options is already
ignored pretty well, so how hard is it to just create such a policy
and go about shooting down people who've messed up?  In all fairness,
most people on the mailing list are terse and, shall we say,
aggressive.  I don't really see there being much of a problem with a
few extra faulty bug reports.  I feel that the good done would
outweigh the slight overhead of a few idiots.

>
> > It just seems that much use could be made out of this, both in terms
> > of (sane) optimizations
>
> Sane optimizations should be added to main Makefile.
>
> > and easier access to enhanced debugging
> > opportunities.
>
> Which ones exactly?
>
> > 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).
>
> In general, wrong.
>

Erm... what are you responding to?  I don't know what that "wrong"
refers to.  Especially considering that the paragraph you're
referencing is an opinion and personal thought.
--
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