On Tue, Nov 12, 2024 at 7:42 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Mon, 11 Nov 2024 16:15:41 +0800 Xiao Liang wrote: > > > Let's start with annotating the drivers which need the old behavior. > > > It seems like something that was done as a workaround for old drivers, > > > maybe there isn't that many of them and we can convert them all in one > > > series. > > > > I'd like to clarify a bit here. > > Link netns is closely coupled with source netns, as it's passed to drivers > > as source netns. Without introducing a flag, after applying the logic in > > this patchset, drivers won't be able to distinguish the two: > > 1) ip -n ns1 link add netns ns2 ... > > 2) ip link add netns ns2 link-netns ns1 ... > > True, but the question is how many drivers actually care about the net > parameter. Ideally we would pass both netns to the drivers, refactor > the ->newlink callback to take a parameter struct and add both netns > as members. Passing just one or the other will always be confusing. > Got it, thanks. Will work on a v3. > > There's no problem for drivers that already handle source netns. > > But it changes the semantics of 1) for ip tunnels silently. The effective > > link-netns is ns2 before, and will be changed to ns1 afterwards, which will > > almost certainly affect some users. Is this acceptable? > > No, changing the behavior for the commands you provided is not > acceptable. At the same time we shouldn't be adding technical debt > of supporting both converted and unconverted drivers upstream. > > > On the other hand, do we need to deal with out-of-tree drivers? > > Nope, but again, changing the prototype of newlink would also make it > hard to get wrong for OOT modules.
