[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080730144812.a71156f7.akpm@linux-foundation.org>
Date: Wed, 30 Jul 2008 14:48:12 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc: shemminger@...tta.com, jeff@...zik.org, netdev@...r.kernel.org,
davem@...emloft.net, mpm@...enic.com
Subject: Re: [patch 12/12] Configure out ethtool support
On Wed, 30 Jul 2008 23:35:51 +0200
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com> wrote:
> Le Wed, 30 Jul 2008 14:01:36 -0700,
> Stephen Hemminger <shemminger@...tta.com> a __crit :
>
> > Yes, but still concerned that the loss of functionality. The kernel
> > developers have been preaching to get rid of module parameters for
> > configuration, and use a standard interfaces such as ethtool;then the
> > embedded folks want to save a meager 6K.
>
> I understand your point, and I understand that adding many
> configuration options might not look pretty to everybody (even to me).
> However, the kernel developers want to keep embedded people using recent
> versions of the Linux kernel. Unfortunately, the kernel grows release
> after release (see [1] for a report, for example),
There is no [1].
> making the kernel
> less and less usable in certain constrainted embedded contexts where
> older kernels can be used. And people putting Linux in consumer
> electronics devices sold several millions times really do care about
> system size.
>
> The problem is that this kernel growth is well-spread over all the code.
> So yes, it's 6k here, 10k here, 7k there, but once added, it starts to
> be significant.
I note that everybody thinks that their bit cannot possibly be removed,
and that everyone else's can ;)
But I do think we should see some evidence that people are actually
using CONFIG_ETHTOOL=n in real setups.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists