On Fri, Feb 21, 2014 at 4:31 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > On Fri, Feb 21, 2014 at 4:19 PM, Lennart Poettering > <lenn...@poettering.net> wrote: >> >> Well, ultimately it's up the distributions to decide what they want to >> enable and what not. > > True, but this requires manual patching and fixing up of `make > install`, which is a bummer. > >> I think networkd is a good choice, especially >> since it doesn't break anything without configs around. > > But it shouldn't even run when it doesn't have configs. It seems > totally superfluous and wasteful to do so.
In the not-too-distant future we'll start shipping some configuration files (as Lennart mentioned to do with nspawn). These are files that in most cases will not apply, and shouldn't interfere with your existing networking solutions, but we want them to apply in the very special circumstances that we know are safe (in a nspawn container, on a device we create ourselves with a specific purpose). >> Moreover, we will probably start shipping some .network files by default >> to auto configure the veth tunnels of nspawn automatically. > > Couldn't nspawn then run it, as needed? Seems wasteful to have this > running all the time, especially because most people never even touch > nspawn. We want this (by default) to be a generally available service, so requiring each user of it (nspawn is obivously just the first example) to enable it feels wrong. We don't want to be wasteful though, so please file bugs if you are noticing any problems with resource usage... >> This is the >> kind of functionality that should just work and that is not available >> out-of-the-box with other managers, since they tend not to run in >> containers. > > Having it not enabled by default doesn't destroy the out-of-box > functionality, since configuration files need to be written anyway. An > administrator will write this configs, and then type "systemctl enable > systemd-networkd". Otherwise, it doesn't need to be running. As I mentioned above, we'll likely start shipping these files by default, so that they really work out-of-the-box. If you are experiencing any real technical, measurable problems, please let me know. Otherwise, I don't think there is anything to do here. Sorry about that. Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
