El mié, 8 de oct 2014 a las 10:24 , Marcel Holtmann <marcel@holtmann.org> escribió:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Hi Cameron,

<blockquote><blockquote><blockquote><blockquote><blockquote> 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.) ?
</blockquote> 
 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).
</blockquote> 
 Does the C API allow programs to temporarily stall bringing up or down
 the interface, or does it only deliver signals of if state?
</blockquote> 
 No it does not allow synchronous hooks. Only asynchronous notification
 is supported.
 
<blockquote> 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)?
</blockquote> 
 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.
</blockquote> 
 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).
</blockquote>
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.</div></blockquote><div><br></div><div>udev was indeed my first thought for ethtool, however how would the ethtool commands be hooked in on containers? Or is ethtool not relevant there?</div><div><br></div><div>Thanks,</div><div>--</div><div>Cameron</div>