Phil Sutter <phil@xxxxxx> wrote: > On Thu, Jul 03, 2025 at 12:39:32AM +0200, Florian Westphal wrote: > > > - A wildcard interface spec is accepted as long as at least a single > > > interface matches. > > > > Is there a reason for this? Why are they handled differently? > > I wasn't sure if it's "required" to prevent it as well or not. This > patch was motivated by Pablo reporting users would not notice mis-typed > interface names anymore and asking for whether introducing a feature > flag for it was possible. So I went ahead to have something for a > discussion. Ah, thanks, that makes sense. > Actually, wildcards are not handled differently: If user specifies > "eth123", kernel errors if no "eth123" exists and accepts otherwise. If > user specifies "eth*", kernel errors if no interface with that prefix > exists and accepts otherwise. Indeed, thanks for clarifying. > I don't know where to go with this. If the flag should turn interface > specs name-based, its absence should fully restore the old behaviour (as > you kindly summarized below). If it's just about the typo, this patch > might be fine. Yes. > > Now (this patch, without new flag): > > - netdev basechain: same as above. > > But you do get an error if the device name did not exist. > > Unless it was for "foo*", thats accepted even if no match is found. > > No, this patch has the kernel error also if it doesn't find a match for > the wildcard. It merely asserts that the hook's ops_list is non-empty > after nft_netdev_hook_alloc() (which did the search for matching > interfaces) returns. Aaah, ok, I see now. Then its waaaay less confusing than I thought. > > If in doubt the flag should not be updateable (hard error), in > > that case we can refine/relax later. > > My statement above was probably a bit confusing: With non-persistent, I > meant for the flag to be recognized upon chain/flowtable creation but > not added to chain->flags or flowtable->data.flags. I see, thats a good question, I feel exposing it (add to ->flags member) is better.
