Hi Cameron,

>>>>> ifupdown [1], NetworkManager, and WICD all support hooks for when a
>>>>> network interface is configured or deconfigured (before and after
>>>>> these actions).
>>>>> 
>>>>> Are there any plans to support something along these lines? If so,
>>>>> what will that look like?
>>>>> 
>>>>> If there are no plans, how do networkd's developers feel about adding
>>>>> the feature (will not merge, or will accept patches, etc.) ?
>>>> 
>>>> I am sceptical to adding hooks, so would need a lot of convincing.
>>>> What we do, however, is to expose the configuration state using the
>>>> sd-network C API, which external programs can watch and react on (see
>>>> how timesyncd and resolved currently works).
>>> 
>>> Does the C API allow programs to temporarily stall bringing up or down
>>> the interface, or does it only deliver signals of if state?
>> 
>> No it does not allow synchronous hooks. Only asynchronous notification
>> is supported.
>> 
>>> Out of curiosity, where does your aversion to hooks come from? Does it
>>> add significant complication code wise, or is it more with respect to
>>> using networkd before any filesystems are mounted (thus the hook files
>>> would not be present)?
>> 
>> Well, we want networkd to be clean and properly written, and I simply
>> have the suspicion that if start allowing glueing in badly integrated
>> stuff via shell scripts, we'll have a hard time to ever fix this
>> again. I mean, network management solutions that shell out to external
>> tools we have enough, but networkd is really not supposed to be like
>> that. It shouldn't just be a glued together thing, but somewhat
>> uniform.
> 
> Ok, that is a good reason, what I had slightly imagined.
> 
> Now that I have looked in the hook dirs of ifupdown more closely, I
> have noticed pretty much only async stuff, except for some ethtool,
> wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems
> like it may be misplaced, and is probably just fine in post-down
> (which is async, compared to down).

actually not using avahi-autoipd is the way you really want to go. Especially 
since networkd will do IPv4LL setup for you anyway. Same applies to ethtool 
hooks since they should be done by link files and configured by udev.

For the wpa_supplicant, we are going to fix that one with a proper daemon soon.

Regards

Marcel

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to