On Wed, Oct 27, 2021 at 02:32:31PM +0100, Jason McIntyre 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.
> > 
> > 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.

makes sense to me.

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

dlg@rpi3b trees$ ifconfig -C
aggr bpe bridge carp egre enc eoip etherip gif gre lo mgre mpe mpip mpw nvgre 
pair pflog pflow pfsync ppp pppoe svlan switch tap tpmr trunk tun veb vether 
vlan vport vxlan wg

the "interface can be created paragraph" is in most of the manpages for
these drivers, except for pair, pfsync, pppoe, and vether (and
veb/vport). some of them could be improved, eg, bpe and switch.

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

Reply via email to