[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the Release Team - Kicking off Wheezy

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 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

Reply to: