On Thu, 30.04.15 12:57, Rauta, Alin (alin.ra...@intel.com) wrote: > Hi Tom, Lennart, > > I have some questions regarding dbus API and run-time networkd configuration. > I would really appreciate your answers/suggestions. > > First, when upstreaming BridgeFDB support in networkd, I had (in the first > place) a patch composed of 2 parts: > > - One part for clearing existing configuration; > > - One part for setting new FDB entries; > > Since networkd doesn't currently clear existing configuration, only the first > part of the patch was accepted. > > At that time you said that: > > "In the future we plan to get a dbus API where networkd can be > reconfigured at run-time (i.e., change which .network file is > applied to a link), and then it definitely would make sense to flush > routes and addresses when removing the .network from the link, but > currently we don't do that at all." > > Do you have any updates or more information on dbus API (how would > this be actually done, how would work) ?
Not really, nobody hasbeen working on adding any API for this yet. Given the delays around kdbus I think we should start adding an API for this now however, but this requires careful consideration I figure. I'll try to get this process started with Tom. > What extensions to existing networkd functionality would the dbus > API bring ? Well, initially it will just open up what we already have. i.e. it will carry an API for creating .netdev interface, and for applying .link and .network files to interfaces. > Second, regarding "BindCarrier=" functionality, would dbus API make > it possible to modify the string content or the bind carrier > functionality at run-time ? Yes, but I think this would be the second step... > Moreover, we currently have the case where networkd is running and > has some ports involved in "BindCarrier=" dependencies. Then some of > this ports are run-time added to a team (link aggregation) device > (maybe through command line). In this case the carrier dependencies > affect the team device functionality creating confusion at one point > in time (team tries to get the childs up/down, but the functionality > is affected by the carrier dependencies between childs or between > childs and other ports outside of the team device). Would dbus API > be of any help in this case ? or Do you have any suggestions on how > to avoid these cases ? well, sure, if we make BindCarrier= dynamically settable, then you should be able to cover this nicely... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
