starting netconf development

Simon Kelley 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 [0], my brain
> today decided to start on the netconf [1] 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
> [2] 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
> [3] and slides from my last talk [4]. Then subscribe.
> 

I'd like to contribute to this: I won't be at DebCamp, but I will be at 
DebConf.

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

ifup eth1

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.


Cheers,

Simon.




More information about the netconf-devel mailing list