Hi Jouke, On Sun, Dec 1, 2013 at 4:06 PM, Jouke Witteveen wrote:

On Thu, Nov 28, 2013 at 8:38 PM, Tom Gundersen wrote:

...

I wrote a bit about the background/status on G+: https://plus.google.com/+TomGundersen/posts/bDQCP5ZyQ3h (there are a few more posts with more details). If any of you have any feedback, or would like to contribute, let me know.

This work is certainly relevant to netctl. I even think you somewhat misrepresented netctl in you announcements, as netctl ticks quite a few of your boxes:

Sorry about that. That was not my intention. I guess that most of the other networking solutions do in fact tick most of the boxes (but I'd claim that none of them tick them all).

it is rather minimal, it has an easy to use plain-text configuration format, and on top of that it harnesses as much of the power of systemd as possible (netctl even mimics the syntax of systemctl for completely intuitive usage). More or less the only difference between networkd and netctl is that networkd targets static configurations, while netctl targets dynamic configurations (profiles).

That's all correct, but there is also one additional point: we want an implementation that can integrate all the state machines we will eventually have (i.e., the rtnetlink one, together with the various protocols such as DHCPv4, DHCPv6, DNAv4, IPv4LL) into one. So calling out to external tools the way netctl does is something we'd like to avoid.

I do think netctl can benefit from networkd. There are a few things I'd like to get a response on.

I hope so!

This list might not be the right place for them, so maybe I repost these things to the systemd list soon.

The first thing I would like a response on is actually a statement. I would like to know how far off it is. As I see it, networkd implements the functionality of the ip utility of iproute2 inside systemd and adds a dhcp client to it.

Yes, that is correct. Both networkd and iproute2 are implemented on top of the kernels rtnetlink interface, so (at least in principle) they could expose the same functionality. We intend to add much more to it though, in particular various the various DHCP-like protocols listed above. We will probably see even more as time goes by.

Next are a couple of questions, where I will pretend the above statement holds some truth. The questions are basically just one question asked a couple of times.

Will the functionality that networkd shares with ip (link and address management) be exposed by a script-friendly (non-dbus) command?

It will certainly be exposed on dbus, and then we will have networkctl, which will expose what makes sense (maybe everything?) to scripts.

Will the dhcp server be exposed?

We will have to get back to the details of exactly how these things are exposed, but I expect static ip's and dhcp will be exposed in the same way. The way I expect it to work is that a client would have to atomically feed in (the equivalent of) a .network file to networkd and tell it to apply it to a certain link, and let networkd sort out the order in which to do things, what events to wait for etc.

Will beat detection be exposed, for instance by starting/stopping a systemd service when a cable is plugged/unplugged?

It will certainly be exposed over dbus, and it will probably be a way to query the state via networkctl, I doubt networkd itself will directly start/stop systemd units based on link detection, but that's obviously something a third-party daemon could implement on top of the dbus interface.

If the answer to the last question is yes, this would finally make ifplugd a thing of the past.

Hopefully its author will not be too upset ;-) Cheers, Tom

On Sun, Dec 1, 2013 at 6:52 PM, Gerardo Exequiel Pozzi wrote:

On 11/28/2013 04:38 PM, Tom Gundersen wrote:

...

Hi guys, and Jouke in particular,

In case any netctl developers have not yet seen/heard about networkd, I thought I'd give you a heads-up about it.

networkd is an (at the moment) very basic network solution for statically configured networks, and probably shares some usecases with netctl. It will ship with systemd v209.

I wrote a bit about the background/status on G+: https://plus.google.com/+TomGundersen/posts/bDQCP5ZyQ3h (there are a few more posts with more details). If any of you have any feedback, or would like to contribute, let me know.

Cheers,

Tom

Hello Tom

Thanks for the very good :)

Is there any intention to supoort, in a future, the IP= kernel command line parameter? This is used for PXE in initramfs stage.

We definitely want to support networking in the initramfs. I must admit I don't know much about PXE, but the ip= syntax, seems like a natural thing to support (similarly to how we support other kernel parameters like root=, etc). I suppose we could simply ship a generator in our initramfs which would parse the kernel commandline and write out an /run/systemd/network/00-cmdline.network. This would likely also support more advanced stuff than the ip= parameter as it is needed by stuff like dracut (so Harald is interested in that). Note that we don't yet support all the features ip= need, in particular we don't do anything about dns yet. Cheers, Tom