All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Fedyk <mfedyk@matchmail.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Adrian Bunk <bunk@fs.tum.de>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Bloat report 2.6.3 -> 2.6.4
Date: Mon, 22 Mar 2004 14:51:36 -0800	[thread overview]
Message-ID: <405F6DF8.4060307@matchmail.com> (raw)
In-Reply-To: <20040314005726.GS20174@waste.org>

Matt Mackall wrote:
> On Sun, Mar 14, 2004 at 01:32:20AM +0100, Adrian Bunk wrote:
> 
>>On Sat, Mar 13, 2004 at 05:59:40PM -0600, Matt Mackall wrote:
>>
>>>On Sat, Mar 13, 2004 at 06:57:13PM +0100, Adrian Bunk wrote:
>>>...
>>>
>>>>>But I think it's fair to say that new features that are on by default
>>>>>are in fact bloat in some sense.
>>>>
>>>>Perhaps in some sense, but not in any interesting sense.
>>>>
>>>>For the average computer you can buy at your supermarket today it isn't 
>>>>very interesting whether the kernel is bigger by 1 MB or not.
>>>>
>>>>People who need to care about the size of the kernel [1] use hand-tuned 
>>>>.config's that are far away from defconfig - and those people wouldn't 
>>>>enable unneeded features that are on by default.
>>>
>>>And my coverage of creep in other _commonly used_ parts of the kernel
>>>would then be nil. Given that allyesconfig can't be expected to build
>>>a kernel on any given day, defconfig is the least arbitrary and most
>>>useful of arbitrary choices.
>>>
>>>
>>>>You use a metric "size increase of a defconfig kernel [2]", and I simply 
>>>>claim that this metric doesn't measure anything useful for practical 
>>>>purposes.
>>>
>>>defconfig is not an unreasonable approximation of features people use. 
>>
>>What exactly is your goal?
>>
>>As already said:
>>  *** For the average user, the size of the kernel doesn't matter *** [1]
>>  *** People that care about size don't use defconfig ***
> 
> 
> Neither of these things matter. The important thing is that defconfig
> encompasses a range of common options that are likely to be used, thus
> people care about growth in those areas regardless of what subset or
> superset they actually use. It is not possible to see growth in the
> code for option FOO if option FOO is not enabled. As I pointed out in
> the last message, allyesconfig would be ideal for my purposes and
> fails both of the above quite dramatically.

With CONFIG_BROKEN, in the kernel for a while, why doesn't allyesconfig 
work on a stock kernel?  Maybe there are some logic errors in kconfig...

  reply	other threads:[~2004-03-22 22:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-12 20:44 Bloat report 2.6.3 -> 2.6.4 Matt Mackall
2004-03-12 23:22 ` Andrew Morton
2004-03-12 23:53   ` Matt Mackall
2004-03-13 17:08     ` Adrian Bunk
2004-03-13 17:33       ` Matt Mackall
2004-03-13 17:57         ` Adrian Bunk
2004-03-13 23:59           ` Matt Mackall
2004-03-14  0:32             ` Adrian Bunk
2004-03-14  0:57               ` Matt Mackall
2004-03-22 22:51                 ` Mike Fedyk [this message]
2004-03-24 17:22           ` Tim Bird
2004-03-13 22:17         ` Sam Ravnborg
2004-03-14  0:15           ` Matt Mackall
2004-03-14 21:03           ` John Cherry
2004-03-13 23:34     ` Horst von Brand

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=405F6DF8.4060307@matchmail.com \
    --to=mfedyk@matchmail.com \
    --cc=akpm@osdl.org \
    --cc=bunk@fs.tum.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.