[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080731085916.232f4c31@extreme>
Date: Thu, 31 Jul 2008 08:59:16 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: Matt Mackall <mpm@...enic.com>
Cc: David Miller <davem@...emloft.net>, dwmw2@...radead.org,
akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
thomas.petazzoni@...e-electrons.com, jeff@...zik.org,
netdev@...r.kernel.org
Subject: Re: [patch 12/12] Configure out ethtool support
On Thu, 31 Jul 2008 10:36:31 -0500
Matt Mackall <mpm@...enic.com> wrote:
>
> On Thu, 2008-07-31 at 03:47 -0700, David Miller wrote:
> > I especially appreciate that you still haven't accepted the plain fact
> > that CONFIG_ETHTOOL needs to be selected by CONFIG_INET.
>
> So far the following features have been mentioned as being critically
> dependent on ethtool:
>
> - bridging
> - bonding
> - LRO
> - netfilter (really?)
> - IPv6 (really?)
>
> And yet every single one of these is currently a config option, so your
> above statement is still looking awfully dubious. At this point I'd
> suggest that you've painted yourself into a corner where all these
> options must also actually be mandatory, but I'm afraid you might
> secretly want to do that anyway.
>
> > I definitely see the next consequence of the CONFIG_ETHTOOL stuff, and
> > that's a set of ifdef'ola in all the drivers to config out the
> > per-driver ethtool support code.
>
> If someone shows up with such a patch for a Xylinx or ARM SOC device,
> you probably should take it. If the patch is instead for a 10Gb PCIe
> device, I suggest you don't. (At least not until that sort of thing
> becomes standard embedded kit.)
>
I have no problem with an embedded CONFIG_ETHTOOL that normal users
can ignore. Just don't expect the network developers to fix things
that are broken when CONFIG_ETHTOOL is not enabled. I.e if embedded
build is broken it is your problem.
--
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