starting netconf development
simon at thekelleys.org.uk
Tue May 8 20:49:41 UTC 2007
martin f krafft wrote:
> Even though I am still somewhat physically limited , my brain
> today decided to start on the netconf  development. And since we
> all know that the waterfall model is the One True Model and that
> Extreme Programming no solution, I started by drafting a document,
> nothing formal, just thoughts on how to implement the various parts
> of netconf. And open questions I already know need to be answered.
> I shall be posting this document to the netconf-devel mailing list
>  sometime soon and am looking for comments (and answers and
> helpers). The purpose of this message is to get interested people to
> subscribe. Please do so that we can keep debian-devel free of this
> and so that I can get more feedback (and potentially help).
> If you don't know what I am talking about, check out the wiki page
>  and slides from my last talk . Then subscribe.
I'd like to contribute to this: I won't be at DebCamp, but I will be at
A couple of contributions I can throw in for starters:
1) A backwards-compatible daemon architecture.
ifup/ifdown currently just exec a set of binaries (ip, ifconfig,
dhclient, etc) depending on the interface configuration. std(in|out|err)
for those processes is inherited from ifup, so you can do
on the command line, and see the output from the ifconfig process, etc.
If we want to make a persistent daemon, and turn ifup into something
which pokes the daemon, then we can use a unix-domain socket to talk to
the daemon, and pass file descriptors over the socket so that the daemon
has the correct file descriptors from a particular ifup process and
passes those to child processes. I have some C code which makes this work.
2) DHCP client.
I have something called "diamond" which is a self-contained DHCP client
which talks D-bus and provides an interface to query arbitrary DHCP
options, either from the original DHCPACK packet, or by doing a fresh
DHCPINFORM query to the server. I've never really pushed this in its
current form, but it could form the basis of the DHCP code in netconf.
I agree with madduck that we should go for waterfall. I've failed to
raise the activation energy to really start on this for a year now, but
if we just start doing something, it could just happen.
More information about the netconf-devel