The kernel compilation fails with allnoconfig with an unresolved to init_net.
I tryed to figure out how to fix that. The problem is raised because the init_net
variable is defined as extern in net_namespace.h while the variable is declared
in net_namespace.c. This file is not compiled because of the config options and
that leads to the compilation error.

I noticed the uts namespace defines the init_uts_ns in init/version.c, so I moved
the init_net to this file too. The compilation error is fixed.

But I don't like really this approach because:
	1 - we fall under a part not covered by the network
	2 - we add a new include net_namespace.h in version.c

Does this fix seems correct ? I just want to fix it for now to have net-2.6.24
compiling for all configs.

-- 
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Fix allnoconfig compilation error

Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
---
 init/version.c           |    4 ++++
 net/core/net_namespace.c |    3 ---
 2 files changed, 4 insertions(+), 3 deletions(-)

Index: net-2.6.24/init/version.c
===================================================================
--- net-2.6.24.orig/init/version.c
+++ net-2.6.24/init/version.c
@@ -12,6 +12,7 @@
 #include <linux/utsname.h>
 #include <linux/utsrelease.h>
 #include <linux/version.h>
+#include <net/net_namespace.h>
 
 #define version(a) Version_ ## a
 #define version_string(a) version(a)
@@ -33,6 +34,9 @@ struct uts_namespace init_uts_ns = {
 };
 EXPORT_SYMBOL_GPL(init_uts_ns);
 
+struct net init_net;
+EXPORT_SYMBOL_GPL(init_net);
+
 /* FIXED STRINGS! Don't touch! */
 const char linux_banner[] =
 	"Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@"
Index: net-2.6.24/net/core/net_namespace.c
===================================================================
--- net-2.6.24.orig/net/core/net_namespace.c
+++ net-2.6.24/net/core/net_namespace.c
@@ -19,9 +19,6 @@ LIST_HEAD(net_namespace_list);
 
 static struct kmem_cache *net_cachep;
 
-struct net init_net;
-EXPORT_SYMBOL_GPL(init_net);
-
 void net_lock(void)
 {
 	mutex_lock(&net_list_mutex);

-- 
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

dlezcano@fr.ibm.com writes:

> The kernel compilation fails with allnoconfig with an unresolved to init_net.
> I tryed to figure out how to fix that. The problem is raised because the
> init_net
> variable is defined as extern in net_namespace.h while the variable is declared
> in net_namespace.c. This file is not compiled because of the config options and
> that leads to the compilation error.
>
> I noticed the uts namespace defines the init_uts_ns in init/version.c, so I
> moved
> the init_net to this file too. The compilation error is fixed.
>
> But I don't like really this approach because:
> 	1 - we fall under a part not covered by the network
> 	2 - we add a new include net_namespace.h in version.c
>
> Does this fix seems correct ? I just want to fix it for now to have net-2.6.24
> compiling for all configs.

Thanks for the testing and catching all of the little nit picky things.

Where is init_net used that is a problem with allnoconfig?

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

dlezcano@fr.ibm.com writes:

> The kernel compilation fails with allnoconfig with an unresolved to init_net.
> I tryed to figure out how to fix that. The problem is raised because the
> init_net
> variable is defined as extern in net_namespace.h while the variable is declared
> in net_namespace.c. This file is not compiled because of the config options and
> that leads to the compilation error.

Ok.  We seem to have the same issue with the ipc namespace.
And it uses the INIT_IPC_NS macro to handle it.

I wonder if we can do something similar here.

It looks like the initialization of nsproxy is the big gotcha.

> I noticed the uts namespace defines the init_uts_ns in init/version.c, so I
> moved
> the init_net to this file too. The compilation error is fixed.
>
> But I don't like really this approach because:
> 	1 - we fall under a part not covered by the network
> 	2 - we add a new include net_namespace.h in version.c
>
> Does this fix seems correct ? I just want to fix it for now to have net-2.6.24
> compiling for all configs.

I think we can probably spend a couple more hours and fix things cleanly.
If that we can't figure out a clean solution I'm happy to deal with the
hack.  But if we can find something clean and maintainable I would
very much prefer that.

So do you think you can come up with something based on the model
of INIT_IPC_NS?

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Eric W. Biederman wrote:
> dlezcano@fr.ibm.com writes:
> 
>> The kernel compilation fails with allnoconfig with an unresolved to init_net.
>> I tryed to figure out how to fix that. The problem is raised because the
>> init_net
>> variable is defined as extern in net_namespace.h while the variable is declared
>> in net_namespace.c. This file is not compiled because of the config options and
>> that leads to the compilation error.
> 
> Ok.  We seem to have the same issue with the ipc namespace.
> And it uses the INIT_IPC_NS macro to handle it.
> 
> I wonder if we can do something similar here.
> 
> It looks like the initialization of nsproxy is the big gotcha.
> 
>> I noticed the uts namespace defines the init_uts_ns in init/version.c, so I
>> moved
>> the init_net to this file too. The compilation error is fixed.
>>
>> But I don't like really this approach because:
>> 	1 - we fall under a part not covered by the network
>> 	2 - we add a new include net_namespace.h in version.c
>>
>> Does this fix seems correct ? I just want to fix it for now to have net-2.6.24
>> compiling for all configs.
> 
> I think we can probably spend a couple more hours and fix things cleanly.
> If that we can't figure out a clean solution I'm happy to deal with the
> hack.  But if we can find something clean and maintainable I would
> very much prefer that.
> 
> So do you think you can come up with something based on the model
> of INIT_IPC_NS?

Sure, I will send it in a few hours ...


_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Daniel Lezcano <dlezcano@fr.ibm.com> writes:

> Sure, I will send it in a few hours ...

Thanks.

Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers