On Thu, Oct 28, 2021 at 04:06:39PM +0100, Stuart Henderson wrote: > On 2021/10/28 13:11, David Gwynne wrote: > > On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote: > > > On 2021/10/27 17:44, David Gwynne wrote: > > > > > > > > > benno@ suggested I look at vether(4) to adapt the text related to > > > > > bridge(4) but I'm not sure how to rewrite it properly for veb(4). > > > > > > > > i get that, but for a different reason. im too close to veb/vport, so i > > > > think it's all very obvious. > > > > > > > > maybe we could split the first paragraph into separate ones for veb > > > > and vport, and flesh them out a bit. what is it about vport that > > > > needs to be said? > > > > > > I'm not so close to veb/vport (and haven't run into a situation to use > > > it yet, though maybe I'll give it a try converting an etherip/ipsec > > > bridge that I have). I think it's pretty obvious too, though I think > > > people aren't grasping what "the network stack can be connected" means, > > > would the diff below help? it feels a bit more like spelling things out > > > than is usual for a manual page but maybe that's needed here. > > > > I think it is needed here. My only issue is that the layer 3 stack is > > more than just IP, it also includes mpls and pppoe and bpe(4). Listing > > all that is heading into "list all the things" territory again though. > > I'll commit it with this tweaked a bit > > +They are then independent of the host network stack: the individual > +Ethernet ports no longer function as independent devices and cannot > +be configured with > +.Xr inet 4 > +or > +.Xr inet6 4 > +addresses or other layer-3 features themselves. > > happy to tweak further, but I think it's an improvement already
that's better than all the attempts i came up with myself. ok by me. > > > > for ifconfig I would be in favour of _not_ listing all the possible > > > cloneable interface types that can be used with create, it's just another > > > thing to get out of sync - maybe just a few of the common ones and tell > > > the reader about ifconfig -C at that point.. "ifconfig create" barely > > > seems necessary except possibly for tun/tap - for most interface types > > > you are going to run another ifconfig command (like "ifconfig veb0 add > > > em0") which creates the interface automatically anyway. > > > > Having clonable interfaces be implicitly created is something that > > annoys me. If I ifconfig bridge0 add gre0, it should actually fail > > without side effects such as bringing an unwanted child^Winterface > > into the world. This and other implicit behaviours like bringing > > an interface up when an address on it is configured are also painful > > from a locking point of view, even after trying to figure out what's > > reasonable to clean up when a later step fails. > > > > I seem to lose this argument every time though. > > The "auto up when configuring an address" is very convenient but > it can result in actual problems too (pppoe needs to know > which protocols to negotiate so it's racy) as well as making > locking painful mmm.
