[GIT] : Networking for 2.6.28

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 11 Oct 2008 10:57:29 -0700 (PDT)

> 
> 
> On Sat, 11 Oct 2008, Linus Torvalds wrote:
> > 
> > On Fri, 10 Oct 2008, David Miller wrote:
> > > 
> > > Here are the queued up networking changes for the 2.6.28 merge window.
> > 
> > This generates _tons_ of new warnings for me:
> 
> And apparently errors for others:
> 
>  net/netfilter/ipvs/ip_vs_xmit.c: In function 'ip_vs_tunnel_xmit':
>  net/netfilter/ipvs/ip_vs_xmit.c:616: error: implicit declaration of function 'ip_select_ident'
> 
> some other config-dependent breakage.

So the proper include (of net/ip.h) is there in ip_vs_xmit.c, but this
failure can also happen if CONFIG_INET is not enabled.

Are you doing that kind of test build?

This patch should fix that case, let me know if it works:


ipvs: Add proper dependencies on IP_VS, and fix description header line.

Linus noted a build failure case:

net/netfilter/ipvs/ip_vs_xmit.c: In function 'ip_vs_tunnel_xmit':
net/netfilter/ipvs/ip_vs_xmit.c:616: error: implicit declaration of function 'ip_select_ident'

The proper include file (net/ip.h) is being included in ip_vs_xmit.c to get
that declaration.  So the only possible case where this can happen is if
CONFIG_INET is not enabled.

This seems to be purely a missing dependency in the ipvs/Kconfig file IP_VS
entry.

Also, while we're here, remove the out of date "EXPERIMENTAL" string in the
IP_VS config help header line.  IP_VS no longer depends upon CONFIG_EXPERIMENTAL

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/netfilter/ipvs/Kconfig |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

On Sat, 11 Oct 2008, David Miller wrote:
> 
> So the proper include (of net/ip.h) is there in ip_vs_xmit.c, but this
> failure can also happen if CONFIG_INET is not enabled.
> 
> Are you doing that kind of test build?

No, but somebody is.

> This patch should fix that case, let me know if it works:

How about you test it? It wasn't my bug-report, I just reported another 
report from somebody who _does_ run randconfig.

Here's another one:

	drivers/built-in.o: In function `bt_poll_rfkill':
	toshiba_acpi.c:(.text+0x37346): undefined reference to `input_event'

where the cause seems to be a totally broken Kconfig entry ACPI_TOSHIBA.

You can't just do

	select INPUT_POLLDEV

since that in turn needs all the _other_ input stuff. Yes, yes, things 
like various keyboard drivers do exactly that, but they are already inside 
"if INPUT_KEYBOARD/INPUT_MISC" or similar.

So at the very least, you'd now have to have it do a "depends on INPUT" or 
something like that.

Or perhaps just make that particular _feature_ depend on it, rather than 
make the whole driver depend on or select it. 

		Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat, 11 Oct 2008 13:10:52 -0700 (PDT)

> On Sat, 11 Oct 2008, David Miller wrote:
> > This patch should fix that case, let me know if it works:
> 
> How about you test it? 

Yep, indeed I did give it a try.

> It wasn't my bug-report, I just reported another 
> report from somebody who _does_ run randconfig.

Where did you see this?  I wouldn't have asked all of these idiotic
questions if I had a link to the report.  Then I could go grab the
config used to produce the problem and then ping the reporter with
a test patch. :-)

> Here's another one:
> 
> 	drivers/built-in.o: In function `bt_poll_rfkill':
> 	toshiba_acpi.c:(.text+0x37346): undefined reference to `input_event'
> 
> where the cause seems to be a totally broken Kconfig entry ACPI_TOSHIBA.

Where are these reports coming from?  Some automated randconfig thing
that gets posted somewhere?  I'd really like to look at this stuff, it
seems very useful.

> You can't just do
> 
> 	select INPUT_POLLDEV
> 
> since that in turn needs all the _other_ input stuff. Yes, yes, things 
> like various keyboard drivers do exactly that, but they are already inside 
> "if INPUT_KEYBOARD/INPUT_MISC" or similar.
> 
> So at the very least, you'd now have to have it do a "depends on INPUT" or 
> something like that.
> 
> Or perhaps just make that particular _feature_ depend on it, rather than 
> make the whole driver depend on or select it. 

Do you want me to fix this ACPI build failure in the networking tree?
I'm more than happy to :-)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html