On Friday 08 December 2006 23:50, Eric W. Biederman wrote:
> Dmitry Mishin <dim at openvz.org> writes:
>
> > Added functions and macros required to operate with current network namespaces.
> > They are required in order to switch network namespace for incoming packets and
> > to not extend current network interface by addtiotional network namespace argue.
> >
> > Signed-off-by: Dmitry Mishin <dim at openvz.org>
> >
> > -#else
> > +#define current_net_ns (current->nsproxy->net_ns)
> > +#else /* CONFIG_NET_NS */
> >
> > #define INIT_NET_NS(net_ns)
> >
> > @@ -57,6 +78,22 @@ static inline int copy_net_ns(int flags,
> > static inline void put_net_ns(struct net_namespace *ns)
> > {
> > }
> > -#endif
> > +
> > +#define current_net_ns NULL
>
> > +#endif /* !CONFIG_NET_NS */
>
> Ouch! NULL is not a good default.
>
> Can we please pick an idiom for referencing global network stack
> variables that works if we are compiled in or not. At least if
> we are going to offer the option.
>
> That way we can merge the changes for looking up all of the globals
> before merging the network namespace support.
>
> Doing it this way seems to imply we will need context support to
> implement this.
>
> My initial suggestion is to base the work on the per cpu variable
> support.
>
> Using __get_net_var(variable). To reference the global variable.
> And the variables marked as __per_net in their declaration so
> we know the variables are per network namespace.
>
> This allows us to handle ipv6 and other modules that only have their
> variables present when they are loaded the same way per cpu variables
> are treated. And it ensures that the form used when everything is
Eric,
please, clarify, what you mean. For example, what we have to do with dev_base,
dev_tail variables?
>
> Eric
>
--
Thanks,
Dmitry.
