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
From: Thomas Petazzoni <[email protected]>
Date: Thu, 31 Jul 2008 11:27:03 +0200
> 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.
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.
On Thu, 2008-07-31 at 02:40 -0700, David Miller wrote:
> From: Thomas Petazzoni <[email protected]>
> Date: Thu, 31 Jul 2008 11:27:03 +0200
>
> > 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.
>
> 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.
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
From: David Woodhouse <[email protected]>
Date: Thu, 31 Jul 2008 10:51:52 +0100
> But there are a lot of people who really don't need these features
> and really want the option of leaving them out.
I'll say it one last time.
If you have ipv4 enabled, you need ETHTOOL.
On Thu, 2008-07-31 at 02:55 -0700, David Miller wrote:
> From: David Woodhouse <[email protected]>
> Date: Thu, 31 Jul 2008 10:51:52 +0100
>
> > But there are a lot of people who really don't need these features
> > and really want the option of leaving them out.
>
> I'll say it one last time.
>
> If you have ipv4 enabled, you need ETHTOOL.
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
From: David Woodhouse <[email protected]>
Date: Thu, 31 Jul 2008 10:59:15 +0100
> 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.
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.
On Thu, 2008-07-31 at 03:02 -0700, David Miller wrote:
> 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.
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
From: David Woodhouse <[email protected]>
Date: Thu, 31 Jul 2008 11:15:16 +0100
> 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.
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.
David Miller wrote:
> From: David Woodhouse <[email protected]>
> Date: Thu, 31 Jul 2008 10:51:52 +0100
>
>> But there are a lot of people who really don't need these features
>> and really want the option of leaving them out.
>
> I'll say it one last time.
>
> If you have ipv4 enabled, you need ETHTOOL.
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
=============================
Tim Bird wrote:
> 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?
...
> Sorry if I missed an earlier explanation.
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
=============================
David Miller wrote:
> 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.
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
=============================
Hi,
>I don't know of any embedded products that ship with NTP turned
>on.
Well, I do. To be exact, I've developed parts of it. But it's numbers
are only into the thousands, so that makes it insignificant ;-)
>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?
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: [email protected] | Listening to:
Stormweg 24 |Pale Bride (The Von Bondies), No Time (Statues),
24539 Neumuenster, Germany|Am Strand (Smoke Blow), Sacred Decay (The Estranged)
On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote:
> Hi,
>
> >I don't know of any embedded products that ship with NTP turned
> >on.
>
> Well, I do. To be exact, I've developed parts of it. But it's numbers
> are only into the thousands, so that makes it insignificant ;-)
>
> >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?
>
> I do not think of NTP as desktop or server application, but that's
> probably just me,
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
On Thu, 2008-07-31 at 15:46 -0400, Josh Boyer wrote:
> On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote:
> > Hi,
> >
> > >I don't know of any embedded products that ship with NTP turned
> > >on.
> >
> > Well, I do. To be exact, I've developed parts of it. But it's numbers
> > are only into the thousands, so that makes it insignificant ;-)
> >
> > >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?
> >
> > I do not think of NTP as desktop or server application, but that's
> > probably just me,
>
> 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.
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
On Thu, Jul 31, 2008 at 03:46:28PM -0400, Josh Boyer wrote:
> > I do not think of NTP as desktop or server application, but that's
> > probably just me,
>
> 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.
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
On Thu, 31 Jul 2008, Josh Boyer wrote:
> On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote:
> >
> > I do not think of NTP as desktop or server application, but that's
> > probably just me,
>
> 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.
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
On Fri, 2008-08-01 at 12:15 -0700, Linus Torvalds wrote:
>
> On Thu, 31 Jul 2008, Josh Boyer wrote:
> > On Thu, 2008-07-31 at 20:50 +0200, Ulrich Teichert wrote:
> > >
> > > I do not think of NTP as desktop or server application, but that's
> > > probably just me,
> >
> > 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.
>
> 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.
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