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 > > 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
