Re: Network namespaces a path to mergable code.

Andrey Savochkin <saw@xxxxxxxxxx> writes:

In a slightly different vein your second patch introduced a lot
of #ifdef CONFIG_NET_NS in C files. That is something we need to look closely
at.

So I think the abstraction that we use to access per network namespace
variables needs some work if we are going to allow the ability to compile
out all of the namespace code. The explicit versus implicit lookup is just
one dimension of that problem.

This is a good comment.

Those ifdef's mostly correspond to places where we walk over lists
and need to filter-out entities not belonging to a specific namespace.
Those places about the same in your and my implementation.
We can think what we can do with them.
One trick that I used on several occasions is net_ns_same macro
which doesn't evalute its arguments if CONFIG_NET_NS not defined,
and thus can be used without ifdef's.

Returning to implicit vs explicit function arguments, I belive that implicit
arguments are more promising in having zero impact on the code when
CONFIG_NET_NS is disabled.
Functions like inet_addr_type will translate into exactly the same code as
they did without net namespace patches.

Which brings us to a basic question. Does it make sense to have
a define that completely disables namespace support.

I know all of the simple namespaces have been implemented like that,
and it was relatively easy there. I'm not at all certain in the long
term we want a configuration option. Especially if simply enabling
the code doesn't have an impact on performance. Which I think is
a merge requirement anyway.

As for inet_addr_type and friends I do agree that implicit arguments
make for an easier implementation of CONFIG_NET_NS. My gut feel
is though that the code with explicit arguments is probably more
comprehensible in the long term. Especially as we find more weird
exceptions where the process we are running in does not have the correct
network namespace.

In general unnecessary CONFIG options are a problem because they make
the entire testing process much harder and make the code harder to
write (so that both cases work and work cleanly).

So my feeling is that we actually want to kill all of those CONFIG_XXX_NS
options.

Which simply leaves us with the problem of implementing the code cleanly.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Network namespaces a path to mergable code.
    ... patches just introducing namespaces for sockets in 2 ways: ... function parameters and using implicit current context. ... So I think the abstraction that we use to access per network namespace ... The explicit versus implicit lookup is just ...
    (Linux-Kernel)
  • Re: I really hate .NET especially inside Delphi
    ... The question answers itself - you can't preserve the implicit make logic ... would the move to explicit make logic bring any ... explicit make system of a language (like Chrome, ... So when I write a class that extends a class in some other namespace, ...
    (borland.public.delphi.non-technical)
  • Re: I really hate .NET especially inside Delphi
    ... The question answers itself - you can't preserve the implicit make ... Since all the tooling around the language is predicated on ... packages, maybe, just maybe a move to explicit make logic would work. ... I can put that class in the namespace it logically belongs in, ...
    (borland.public.delphi.non-technical)
  • Re: Network namespaces a path to mergable code.
    ... relatively short patches just introducing namespaces for sockets ... with explicit function parameters and using implicit ... ability to compile out all of the namespace code. ... versus implicit lookup is just one dimension of that problem. ...
    (Linux-Kernel)
  • Re: Same namespace, different files
    ... If they are in the same assembly you can drop the namespace reference. ... Otherwise the effective namespace will be a union of this implicit project ... The union of the implicit and explicit namespace declarations. ...
    (microsoft.public.dotnet.languages.vb)