(After replying to your message, I noticed that you had sent it as a reply to a much earlier version of the nftables patches sent a year ago to the old mailing list, rather than the most recent version that was pushed, which was very different, and sent to deel(a)lists.libvirt.org, so I'm re-sending my response, but to the new mailing list :-)) On 6/10/24 2:54 PM, Roman Bogorodskiy wrote: Yeah, previously we wouldn't check if iptables was available until someone tried to start a network that would need to use it, and would then log an error (and just fail starting that network, but the network driver would remain running). But now we figure out which firewall backend to use immediately when the driver is loaded, and if we fail to fin a workable backend we fail the entire driver init.r How did you use the network driver before? With a <forward mode='open'/> network? Truthfully I hadn't ever considered the case of someone using it with only network types that didn't need firewall rules. I wonder if there are other platforms we support that have a usable network driver for <forward mode='open'/> (MacOS?) Why not both? :-) Obviously (2) would be nicest, but I guess in the short term some variation of (1) would be quicker. Another possibility could be to restore the old behavior of saving the error and only reporting it when a network requiring a firewall is loaded, but I think I remember a discussion about this during review of an earlier revision of the patches, and we agreed that it made the problem easier to find if it was reported immediately and the driver load failed. I suppose in the long run the build-time option firewall_backend_priority should be used to control which backends are included in the build (rather than just which ones are checked at runtime), so that FreeBSD could completely skip all the iptables and nftables code (and firewalld when that's done), and Linux platforms could skip pf and ipfw. I'm about to be offline for 3 weeks, but in the meantime if you'd like to try making a NULL backend that is only an option if it's listed in firewall_backend_priority (you'll need to remove the compile-time check that all possible backends are accounted for - I think that is the first of the two G_STATIC_ASSERTS at the top of virNetworkLoadDriverConfig()), always initializes successfully in bridge_driver_conf.c if it is listed in the options, and then in networkAddFirewallRules add a check to log an error and fail if backend == NULL (something about attempting to start a network type that would require firewall rules, but the system not having any of the supported types of firewallbackend or something - it's too late now and my brain is too fried and sleepy to think of good wording :-)). As long as it isn't a valid selection on Linux builds that are done with firewall_backend_priority=nftables,iptables, but *is* a valid selection if the setting is "firewall_backend_priority=null" that shouldn't be *too* controversial. Later we can talk about pf and ipfw backends :-)