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. > 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. > > Index: veb.4 > =================================================================== > RCS file: /cvs/src/share/man/man4/veb.4,v > retrieving revision 1.2 > diff -u -p -r1.2 veb.4 > --- veb.4 23 Feb 2021 11:43:41 -0000 1.2 > +++ veb.4 27 Oct 2021 09:03:49 -0000 > @@ -28,20 +28,30 @@ The > .Nm veb > pseudo-device supports the creation of a single layer 2 Ethernet > network between multiple ports. > -Ethernet interfaces are added to the bridge to be used as ports. > +Ethernet interfaces are added to the > .Nm veb > -takes over the operation of the interfaces that are added as ports > -and uses them independently of the host network stack. > -The network stack can be connected to the Ethernet network managed > -by > +bridge to be used as ports. > +Unlike > +.Xr bridge 4 , > .Nm veb > -by creating a > +takes over the operation of the interfaces that are added as ports. > +They are then independent of the host network stack; the individual > +Ethernet ports no longer function as independent layer 3 devices > +and cannot be configured with > +.Xr inet 4 > +or > +.Xr inet6 4 > +addresses themselves. > +.Pp > +The Ethernet network managed by > +.Nm veb > +can be connected to the network stack as a whole by creating a > .Nm vport > interface and attaching it as a port to the bridge. > From the perspective of the host network stack, a > .Nm vport > interface acts as a normal interface connected to an Ethernet > -network. > +network and can be configured with addresses. > .Pp > .Nm veb > is a learning bridge that maintains a table of Ethernet addresses >
