On Tue, Apr 29, 2014 at 04:45:31PM +0200, Pavel Hrdina wrote:
On 8.4.2014 17:38, Daniel P. Berrange wrote:
> The network and nwfilter drivers both have a need to update
> firewall rules. The currently share no code for interacting
> with iptables / firewalld. The nwfilter driver is fairly
> tied to the concept of creating shell scripts to execute
> which makes it very hard to port to talk to firewalld via
> DBus APIs.
>
> This patch introduces a virFirewallPtr object which is able
> to represent a complete sequence of rule changes, with the
> ability to have multiple transactional checkpoints with
> rollbacks. By formally separating the definition of the rules
> to be applied from the mechanism used to apply them, it is
> also possible to write a firewall engine that uses firewalld
> DBus APIs natively instead of via the slow firewalld-cmd.
>
> Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
> +void virFirewallStartRollback(virFirewallPtr firewall,
> + unsigned int flags)
> +{
> + virFirewallGroupPtr group;
> +
> + VIR_FIREWALL_RETURN_IF_ERROR(firewall);
> +
> + if (firewall->ngroups == 0) {
> + firewall->err = ENODATA;
> + return;
> + }
> +
> + group = firewall->groups[firewall->ngroups-1];
> + group->rollbackFlags = flags;
> + group->addingRollback = true;
> +}
Hi Dan,
The ENODATA error is not defined in freebsd and I'm wondering
whether it should be compiled there? If yes, than we have to
add:
#ifndef ENODATA
# define ENODATA ENOMSG
#endif
into that file.
Yes, this is intended to be usable on freebsd. The ENODATA choice was
kind of arbitrary - I think we could just use EINVAL instead as a safe
bet. This would only ever occur if the caller was ignoring the defined
API usage rules, so only ever likely to see this during devevelopment
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|