public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Adrian Bunk <bunk@kernel.org>
Cc: Tim Bird <tim.bird@am.sony.com>,
	linux-embedded <linux-embedded@vger.kernel.org>,
	linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: RFC - size tool for kernel build system
Date: Thu, 9 Oct 2008 18:03:47 +0200	[thread overview]
Message-ID: <20081009160347.GB17179@logfs.org> (raw)
In-Reply-To: <20081009152151.GB17013@cs181140183.pp.htv.fi>

On Thu, 9 October 2008 18:21:51 +0300, Adrian Bunk wrote:
> 
> The building blocks that would be useful are IMHO:
> - a make target that generates a report for one kernel
>   (like the checkstack or export_report targets)
> - a script that compares two such reports and outputs the
>   size differences
> 
> That's also easy to do, and if that's what's wanted I can send a patch 
> that does it.
> 
> Everything else is IMHO overdesigned.

Please do.

> The real problem is that dumping some scripts into the kernel sources 
> or publishing some data on a webpage doesn't make people use them.
> 
> Like if you run "make checkstack" on the kernel today you can see that 
> drivers allocate arrays > 1 kB on the stack despite checkstack being 
> available...

Funny you should mention that.  Yesterday I noticed that make checkstack
had been ported to five more architectures since my last look at the
code.  It doesn't seem likely that those ports were required by some
pointy-haired boss for feature-completeness.  Someone must actually be
using it.

The very beauty of make checkstack is that you don't even notice whether
it is being used or not.  You point to some drivers that apparently
didn't use it, which is fine.  But how many drivers _did_ use it?  How
many problems have been solved before the patches have ever been posted
for review?  Noone knows.  And that is a good thing.  We want the
problems to get solved and not become visible in the first place.

Bloatwatch imo has the design flaw that it is a central tool hosted on
some server somewhere and only documents the damage once it has
happened.  It would be much better if every developer could run
something simple locally and clean up the mess before anyone else
notices.

I partially agree with you in one point.  It would be even better if
checkstack, bloatcheck, etc. were run automatically on every kernel
compile and developers were forced to look at any problems that come up.
But that would increase compile time, which is bad.  So there needs to
be an off button as well, as there is for sparse - where off is the
default.

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens

  reply	other threads:[~2008-10-09 16:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 21:19 RFC - size tool for kernel build system Tim Bird
2008-10-08 19:09 ` Chris Snook
2008-10-08 19:32   ` Tim Bird
2008-10-09 15:21 ` Adrian Bunk
2008-10-09 16:03   ` Jörn Engel [this message]
2008-10-09 18:34   ` Robin Getz
2008-10-09 23:56   ` Tim Bird
2008-10-10  9:42     ` Geert Uytterhoeven
2008-10-13  4:17     ` Robin Getz

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=20081009160347.GB17179@logfs.org \
    --to=joern@logfs.org \
    --cc=bunk@kernel.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tim.bird@am.sony.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox