[systemd-devel] [RFC][PATCH] networkd: add a basic network daemon

[Marcel Holtmann]

Hi ScotX,

>>> Looking at the feature list, why are you not contributing to connman
>>> instead? It seems you're going to be duplicating a ton of code.... And
>>> connman does what your goal is, meaning you can pre-provision static
>>> configurations without any of the more involved dependencies. It has a
>>> DBus interface for status, configuration etc....
>>> 
>>> I'm frankly shocked a bit, not sure what to say. Maybe this is a great
>>> thing, but, without a doubt someone will want to convert this code
>>> long term into connman / NM, and at that point we have 3 standards,
>>> not 2. Best to try and stick to 2 standards and fix the one that has
>>> the best long-term prospective value.
>> 
>> I have a little bit different viewpoint here. I do not look at what are the low-level technical tasks or the implementation, I look at the users. We have two types of users for networking. The first type is sysadmins and the second type is end users. These two groups are as different as it gets in their use cases and how they expect things to be done.
>> 
>> When I look at sysadmins, then you target servers, datacenters, could and containers. So headless systems that are not mobile. They are mainly Ethernet based and configure once and not worry about anymore. As an extra added benefit some of these have to configure everything as early as the initramfs. And they want simple configuration files and command line tools.
>> 
>> Looking at end users, I see desktop, laptops, phones and all these embedded devices like thermostats, fridges and whatever you can think of. Things where networking can mean also WiFi, cellular even sensor networks like Bluetooth 6loWPAN. It is a dynamic world and needs configuration that is targeted for non-technical people. And end users need a nice UI for their needs. It is also not one UI, there will be many and so APIs need to be simple and designed for that user base in mind.
>> 
>> You normally do not take your 12-core Xeon server to the coffee shop around the corner and want to use its public WiFi with a hotspot login. If you do, please take a picture ;)
>> 
>> Trying to smash these together seems rather crazy to me. I looks simple in the beginning, but the devil is in the details. There is a reason why ConnMan stayed out of the datacenter world. So the way I see it is that networkd should own the initramfs and sysadmin side of things. And ConnMan will handle the end user side. What this means is that both work in harmony together.
>> 
>> Think of it like this, the system boots with networkd in initramfs and then you either start networkd for taking over the initramfs configuration and running in datacenter mode. Or you start ConnMan for running in desktop mode. It is a little bit over-simplified, but I think you get the basic idea.
>> 
>> So networkd and ConnMan for example will share a lot of code. And what we will be doing is to contribute the shared pieces into networkd. One prime example is DHCP of course. And the rest we will figure out as networkd progresses.
> 
> Have you completed your recherche on all the existing implementations for network configuration?
> Have you already looked at netifd? Its authors looked at conman and at NM and decided to write netifd. Its for Wi-Fi and complex configurations, yet the same guys also wrote procd, which is similar to systemd. Its for embedded, so its tiny.

netifd does not contain DHCP. It is one core piece of the puzzle for good network configuration. DHCP itself is also a blunt network layer violation since it operates before and after IP addresses are configured. And that is something you have to deal with.

You have DHCPv4 + IPv4-LL and you have DHCPv6 and all of it needs to work together. You can not just spawn dhclient and hope for the best. It just does not work this way. It is an essential part of your state machine and you need to control it. We build our own DHCP client + server for ConnMan since nothing out there was doing a good job. And as of now, there is still nothing else available.

To be fair, initially ConnMan used dhclient or udhcpc for DHCP configuration, but we knew from the beginning that this is not a sustainable solution. If anybody is interested, they can look up my LinuxCon Vancouver presentation. It has a nice overview and what kind difference it makes.

The guys from Nest are running ConnMan in their thermostat. That runs on 12V lines or battery. I call that pretty much embedded. A router with a constant power source is a large machine compared to that.

> Also, what about Bluetooth? It is wireless and requires some low-level thing, that is "Core OS"-ish.

We have BlueZ for that.

Regards

Marcel