Hi,

This is a resend of the small patch list I sent on July, 29th. I'm
resending the patches because they didn't make it to vger lists for
some setup problem on my side, and because I've been asked by Adrian
Bunk to resend them in order to get proper review.

However, please note that the patches removing ethtool and IGMP have
both been nack-ed by David Miller. The resend of these patches is not
an intent to workaround these NACKs in any way: I'm resending because
I've been asked to do so.

I apologize for the mess, and hope that this time, the mails will
reach vger lists.

Changes since previous post:

 * Add Matt Mackall's Signed-off-by on all patches
 * Make bonding and bridging select ethtool in the ethtool-related
   patch.

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
--

[ message continues ]

From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

The ethtool config option needs to be selected by CONFIG_INET as well,
as per the things I described today.  Which erodes it's usefulness
tremendously.

I also am keeping my stance that I have no current intention of
applying these patches.
--

[ message continues ]

I would very much like you to reconsider, Dave.

We can make them default to 'y' and hide them behind CONFIG_EMBEDDED,
and put in a scary help text that tells people _never_ to turn it off --
and hell, you can even make a taint flag for it if you like. But there
are a lot of people who really don't need these features and really want
the option of leaving them out.

Perhaps we should add a warning printk when one of these features is
'required' but absent. That would help to make it clear when someone has
disabled a feature which they shouldn't have disabled.

Refusing to apply the patches just means that either those people will
get them from elsewhere, or that their kernel will be more bloated than
it needs to be.

-- 
dwmw2

--

[ message continues ]

From: David Woodhouse <dwmw2@infradead.org>

I'll say it one last time.

If you have ipv4 enabled, you need ETHTOOL.
--

[ message continues ]

I have drivers which don't even _have_ ethtool support, and they seem to
work fine. But leaving aside the debate on that point, your statement
also seemed to be covering the other patches, such as the IGMP one and
others which haven't been seen (or perhaps even imagined) yet.

-- 
dwmw2

--

[ message continues ]

From: David Woodhouse <dwmw2@infradead.org>

I explained why I didn't want to apply the IGMP one too.

Andrew didn't like my objections, but that doesn't mean I
need to defend my position further.

Show me a size reduction patch for networking that actually
makes real sense and I'll apply it.
--

[ message continues ]

You said that it was part of the core BSD socket API and "Like TCP and
UDP, multicast capabilities are something applications can always depend
upon being available".

Andrew's response was that embedded devices have full control over their
userspace and that they are in a position to _know_ that they never use
multicast, so your argument is bogus. If they _know_ they don't want
multicast, it makes a lot of sense for them to turn it off.

While I agree with Andrew's observation, I'd also respectfully submit
that your argument is more fundamentally bogus than that. TCP and UDP
are _not_ universally available. They go away if you set CONFIG_INET=n.

-- 
dwmw2

--

[ message continues ]

From: David Woodhouse <dwmw2@infradead.org>

Like I said, people can locally patch their systems if they really
want to rip out fundamental things like multicast support.

Some folks might find it instructive to do a google code search
or similar on the multicast socket options this things dikes out
of the tree.

Even simple things like NTP will spew failures with this CONFIG_IGMP
thing turned off.  And that's just the tip of the iceberg.
--

[ message continues ]

I don't know of any embedded products that ship with NTP turned
on.  It's best to assume, with embedded, that we're not shipping
ANY of the desktop or server applications you are familiar with.
Absent those, does something break in the kernel with multicast
support when IGMP is turned off?
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

--

[ message continues ]

Well, I do. To be exact, I've developed parts of it. But it's numbers

I do not think of NTP as desktop or server application, but that's
probably just me,

CU,
Uli
-- 
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de | Listening to:
Stormweg 24               |Pale Bride (The Von Bondies), No Time (Statues),
24539 Neumuenster, Germany|Am Strand (Smoke Blow), Sacred Decay (The Estranged)
--

[ message continues ]

No, it's not just you.  NTP is useful in cases where things do care
about time but hardware designers were too cheap to put an RTC on the
board.

I will admit that it's use in embedded products is probably very limited
though.

josh

--

[ message continues ]

NTP is a red herring. It has a check for multicast support in its
configure script and wraps it all in #ifdef MCAST anyway.

So even if it _does_ crap out when I build my standard distro kernel
with !CONFIG_IGMP and use the standard distro build of ntpd, that still
isn't particularly relevant to the kind of application where someone
would built a kernel without IGMP support and build their own ntpd to
match.

-- 
dwmw2

--

[ message continues ]

Yes, we also have such customer systems, i.e. one which is used in a
Telemetry application where you can have hundrets of PXA270 data
concentrators that collect data from FPGAs and push them to a PC via
ethernet. As the system does not work without the PC, the hardware
designers decided that they can save hundrets of RTCs.

Or another autonomous data collection system where only one system of
several tens has an RTC...

We used chrony in these cases, as the standard ntputils seem to be
optimized for scenarios where you have permanent network connection,
which is often not the case in embedded applications.

rsc
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

--

[ message continues ]

In fact, didn't one of the netgear firewall/switch/routers end up being 
famous for overloading some NTP service exactly because all the _millions_ 
of routers ended up using the same (incorrect) NTP host?

So NTP is very definitely an embedded thing too.

			Linus
--

[ message continues ]

And it's _still_ a red herring.

I just booted a !CONFIG_IGMP kernel on my workstation and NTP is running
just fine (as is IPv6).

Even though ntpd has a configure test for multicast and can be built
without multicast support at all, it isn't even necessary to build it
that way -- the stock Fedora build of it works just fine.

(Actually, I never managed to get ntpd to work _with_ multicast, but
that's a different issue... :)

-- 
dwmw2

--

[ message continues ]

I've been using and administering Linux for 16 years,
and using it successfully in embedded projects for 10.
Until I stumbled upon this patch in Linux-tiny, I had
never heard of ethtool.  Sony has shipped hundreds
of thousands of products with ETHTOOL turned off.

It sounds like you don't want to talk about it any more,
but could you please give me the 30-second overview
of why ETHTOOL is required for proper ipv4 operation?

If Sony is shipping network-buggy products I certainly
want to know about it.

Sorry if I missed an earlier explanation.

Thanks,
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

--

[ message continues ]

Never mind.  I hadn't read the whole thread yet.

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

--

[ message continues ]