On Sun, 2011-04-03 at 23:13 +0530, Josselin Mouette wrote: > Le dimanche 03 avril 2011 à 20:38 +0800, Paul Wise a écrit : > > The problem with that design is that it isn't based in *fact*. The > > fact is that the kernel is where the current networking status is > > held, controlled and modified. AFAICT the NM authors ignored that fact > > in their designs and are resistant to changing the design. That leads > > me to think that NM is not the way forward. Waiting for someone to > > re-implement netconf in C seems to be the only way forward. > [snip] > > > IIRC netconf communicates with the kernel to know what the current situation is. > > I am not sure this is enough; does the kernel has all the information > you need? Even for a moderately complex setup, I don’t see how it would > scale. If you stack some changes, like adding a bridge or changing > routes, you want to be able to revert to the previous state in a > consistent manner. How can you do that without a daemon that keeps track > of the entire network status for the host? The kernel necessarily holds the working network configuration, though it lacks e.g. credentials for WPA or 802.1x which are handled by user-space. User-space can change that state, and can read the state (including waiting for updates) using netlink. User-space needs to provide policy for potential states, and authentication credentials. I think that what people like about ifupdown (when it works) is that they can say 'put this interface in this state' and then go on to tweak that state. ifupdown often fails at this because it relies on state files that can become stale, and it doesn't understand dependencies. NM fails because it doesn't support many of the configurations that people want, and because it will try to re-enter the configured state again after e.g. a link reset. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part