On 11/06/2013 09:37 AM, Marcel Holtmann wrote:
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.
Regards
Marcel
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.
Also, what about Bluetooth? It is wireless and requires some low-level
thing, that is "Core OS"-ish.
Regards,
ScotX
[1] http://wiki.openwrt.org/doc/techref/netifd
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
