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. > > 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. >
hi. i agree with staurt about "create": this list was once short and made sense. now it just keeps going out of date, without providing any help to the reader. i don;t want to stack diff on diff, but maybe once the veb stuff is sorted i will zap the create list. that strategy does rely on individual driver docs saying upfront that they can be created though, even if using create is not common. i wonder if ifconfig already knows what it can create, and could maybe be more helpful if "create" without an ifname gave a hint. anyway, to that end i'm ok with solene's diff. i'm also ok with your diff, with one tweak: > 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 i think a colon would work better than a semi-colon here, since i think the info after it is essentially an explainer of what independent means. jmc > +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 >
