El mié, 8 de oct 2014 a las 10:24 , Marcel Holtmann
<mar...@holtmann.org> escribió:
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.
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?
Thanks,
--
Cameron
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
