On Sat, 2016-04-02 at 21:49 +0200, Stjepan Groš wrote: > On 30.03.2016 17:26, Thomas Haller wrote: > > Hi, > > > > > > > > > 6. Certain aspects of NMManager are global for every network > > > > > namespace, others are not. For example, sleeping state (or > > > > > should > > > > > it > > > > > be separate for every network namespace so that some network > > > > > namespaces can be suspended?). > > > > > > > > > > 7. Related to 7, the best approach would be to refactor > > > > > NMManager > > > > > itself, but that would make very hard to keep HEAD and MIF > > > > > branches > > > > > in sync. > > > > Right, this was the biggest confusion I had. Your NMNetns takes > > > > over > > > > some work of NMManager, while NMManager is global. I guess that > > > > makes > > > > sense. > > > > But currently it's unclear which instance (NMManager, > > > > NMNetnsController, NMNetns, NMPolicy) does what, and how the > > > > interact > > > > with namespaces. > > > > > > > > I think this is difficult to get right. I think that NMNetns > > > > should > > > > be > > > > as simple as possible and more tell NMManager what to do. > > > > > > If you make NMNetns as simple as possible then NMManager must > > > take > > > care of network related changes within different network > > > namespaces, > > > i.e. new devices, IP addresses,etc. This, in turn, migh require > > > all > > > the methods from NMManager to be extended with additional > > > argument - > > > network namespace - which could possibly complicate things. > > > > > > It seems to me that it is lot easier to basically transform > > > NMManager > > > into NMNetns because root network namespace is just one possible > > > network namespace. All the current functionality done by > > > NMManager > > > within root network namespace should be done in every network > > > namespace. Of course, NMManager should stay, but only with the > > > functionality common to all network namespaces. > > > > Now, it could be that the approach of making NMNetns as simple as > > possible is better approach, but only way to find out is to try to > > make it so - which I think is non-trivial. > So NMNetns is basically becoming what NMManager is with all the per- > namespace responsibilities. Makes sense. > > NMManager stays to be a global manager (intra-namespace). > > I dislike that the name "NMNetns" is a prefix of "NMNetnsController", > but why is NMNetnsController a separate object? It doesn't have much > code and it also has it's own D-Bus path. Maybe those properties and > functions should be merged into the NMManager object. > > > Moving large parts of NMManager to NMNetns is probably the right > solution, but a bit hard to develop in parallel as master progresses. > > If that is done, then there is no need for NMNetnsController because > its functionality should be implemented in NMManager. > > I have one problem now. Namely, function _is_root in NMNetns doesn't > work, or am I doing something wrong? When constructing > NMNetnsController object the first NMNetns is created and that one > should be for root network namespace. I'm using _is_root() to skip > device initialization (for root that is done by NMManager now) but > _is_root() returns FALSE?
Hi Stjepan, The NMPNetns instance that represents the root namespace is nmp_netns_get_initial(). You don't create that one, it's always there. You change to call priv->nmp_netns = nmp_netns_new(); is wrong. This creates a new namespace and switches to it. When you switch namespace at a certain moment, you *must* switch back before you return from the function; that is, you must always call nmp_netns_pop() before your function returns. The reason for that is, that at any point it must be known which namespace is currently active. If you call a function and that function switchs namespace, that function is required to restore the callers namespace before returning. For that reason, I think it's better that nm_netns_new() / nm_netns_init() does *not* call nmp_netns_new() to create a new namespace. Instead, it seems more logical that it takes over the *current* namespace nmp_netns_get_current(). So it's the job of the caller of nm_netns_new() -- create_new_namespace() -- to prepare the namespace. Then, when creating the NMNetns instance for the root namespace, the caller just does not call nmp_netns_new() but stays on the root namespace. At that point, nmp_netns_get_currenty() equals nmp_netns_get_initial() and it just works. Does that make sense? Thomas > > The code with my changes to your branch is on the following URL: > > https://github.com/sgros/NETNS_NetworkManager > > SG >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
