Re: [RFC] Remove more code when IP_MULTICAST=n

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Le Tue, 26 Aug 2008 09:44:31 -0700,
Tim Bird <tim.bird@am.sony.com> a écrit :

> In this particular case, I think we need to show that
> there are valid cases were an embedded product can use networking just
> fine, without IGMP support but with support for multicast.  (I believe
> that's  the slice that this particular patch makes).  IMHO, what's
> needed is a test to show that this works.  This can then be presented
> to the netdev guys, who are, after all much more experienced with the
> networking stuff.  If they can show that multicast does indeed *need*
> IGMP to work correctly, then we need to back off.  The last thing I
> want is to find out in the field that some streaming feature I've
> built into a Sony camera that relies on multicast won't work in lots
> of network configurations.  If that's true, then David is doing me a
> favor by saying No. (Note that I might still make the decision to
> forego a feature for size reasons if the number of instances of
> non-workingness was small.)

The patch doesn't try to get multicast support to work without IGMP,
but tries to remove as much code as possible when multicast support is
not needed.

Two approaches have been tried :

 * The first one, by Matt Mackall, was to add a new CONFIG_IGMP option
   next to the existing CONFIG_MULTICAST option, to disable the parts
   of the IGMP protocol support that were still compiled-in when
   CONFIG_MULTICAST=n

 * The second one, this patch, simply removes the IGMP protocol code
   when CONFIG_MULTICAST=n, because my understanding is that the IGMP
   protocol code is useless when multicast is not used.

I might try to send this second approach to netdev, but it seems that
not everybody agrees on the approach of removing things for the kernel
by adding more and more configuration options. If the network
maintainers don't agree with this approach, then I'm not sure how we
can make this patch progress in any way (and this is not an accusation
towards the network maintainers, they also have valid and good
arguments against the addition of dozens of configuration options to
disable a few KB of code).

Sincerly,

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