On Thu, Jul 03, 2025 at 03:17:06PM +0200, Phil Sutter wrote: > On Thu, Jul 03, 2025 at 02:54:36PM +0200, Florian Westphal wrote: > > Phil Sutter <phil@xxxxxx> wrote: > > > > Do we need new query types for this? > > > > nftables could just query via rtnetlink if the device exists or not > > > > and then print a hint if its absent. > > > > > > Hey, that's a hack! :P > > > Under normal circumstances, this should indeed suffice. The ruleset is > > > per-netns, so the kernel's view matches nft's. The only downside I see > > > is that we would not detect kernel bugs this way, e.g. if a new device > > > slipped through and was not bound. Debatable if the GETDEV extra effort > > > is justified for this "should not happen" situation, though. > > > > Could the info be included in the dump? For this we'd only need a > > 'is_empty()' result. For things like eth*, nft list hooks might be > > good enough to spot bugs (e.g., you have 'eth*' subscription, but > > eth0 is registed but eth1 isn't but it should be. > > That may indeed be a simple solution avoiding to bloat > NEWFLOWTABLE/NEWCHAIN messages. > > > In any case I think that can be added later. > > Right now, NFTA_FLOWTABLE_HOOK_DEVS is just an array of NFTA_DEVICE_NAME > attributes. Guess the easiest way would be to introduce > NFTA_FLOWTABLE_HOOKLESS_DEVS array of NFTA_DEVICE_NAME attributes, old > user space would just ignore that second array. That is, new nftables binaries use NFTA_FLOWTABLE_HOOKLESS_DEVS. > Pablo, WDYT? Feasible alternative to the feature flag? If my understanding is correct, I think this approach will break new nft binary with old kernel.
