On Thu, 27 Feb 2014 20:39:18 +0100 Jouke Witteveen <[email protected]> wrote:
> On Thu, Feb 27, 2014 at 7:20 PM, Leonid Isaev <[email protected]> wrote: > > On Thu, 27 Feb 2014 13:03:27 -0500 > > Dave Reisner <[email protected]> wrote: > > > >> On Thu, Feb 27, 2014 at 12:56:02PM -0500, Leonid Isaev wrote: > >> > On Thu, 27 Feb 2014 14:25:15 +0100 > >> > Jouke Witteveen <[email protected]> wrote: > >> > > >> > > Support for additional DHCP clients is now easy to add. > >> > > >> > Just a quick question: are there any plans to use networkd as a DHCP > >> > backend? Yes, it is config-file-driven, but one can probably generate > >> > the .network files in /run on the fly... > >> > >> This sounds like pointless masturbation. Just use networkd directly. > > > > That's what I originally thought, and (in a nutshell) this is what I am > > currently using. > > > > However, networkd config is based on an interface name, not a profile. > > Hence there are special cases when e.g. 2 wireless networks use different > > settings (dynamic/static IP, different DNS, etc.). In these scenarios one > > needs wpa_actiond. As long as the correct profile is selected, one can > > make use of networkd instead of dhcpcd. > > > > Contrary to networkd, netctl is profile based. This makes netctl > useful in changing environments. > > If networkd exposes its dhcp client, this patch makes it easy to add > support for it to netctl. There are no cli options, only config files. These will need to be generated based on a specific profile. So, the whole situation is similar to the way netctl-auto handles wpa-configsection. > Even better, if networkd exposes a lot of its functionality, netctl > could potentially drop the dependency on iproute2 (not that there is a > problem with iproute2). Yes, static things like bridge, bond, and vlan for which netctl profiles are essentially identical to .net{dev,work} files. I think that the only advantage of netctl over networkd in this case is the ability to specify dependencies (via Before= and After=) between the respective units. > > There are other dhcp clients (such as udhcp) for which support can > already be implemented easily after this patch is applied. > > Regards, > - Jouke Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
signature.asc
Description: PGP signature
