Re: demystify vport(4) in vport(4) and ifconfig(8)
On Thu, Oct 28, 2021 at 01:27:17PM +1000, David Gwynne wrote: > > > 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. > oops, missed that flag! i had thought maybe if there was such an option, we wouldn;t need the "if can be created" blurb in every page. but i suppose we do need to say it somewhere. another issue is that the text is inconsistent across pages. jmc
Re: demystify vport(4) in vport(4) and ifconfig(8)
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 - 1.2 > > +++ veb.4 27 Oct 2021 09:03:49 - > > @@ -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 > >
Re: demystify vport(4) in vport(4) and ifconfig(8)
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 - 1.2 > +++ veb.4 27 Oct 2021 09:03:49 - > @@ -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 >
Re: new site.8: document site*.tgz and /{upgrade,install}.site
Looks good. Nice to see this moving forward. Thanks.
On 2021-10-27 21:13 +, Klemens Nanni wrote:
> On Mon, Sep 06, 2021 at 02:29:50PM -0500, Aaron Poffenberger wrote:
> > Ping.
> >
> > Will someone commit this? Seems like no one knows about /upgrade.site and it
> > fits well with sysupgrade(8).
>
> sysupgrade(8) is one potential /upgrade.site user but I disagree about
> documenting the latter through the former.
>
> Here is a new manual roughly merging the FAQ bits with what you, Aaron,
> provided.
>
> site(8) is a lame but fitting name; autoinstall(8) and sysypgrade(8)
> reference it and both sets and scripts are documented.
>
> Examples are intentionally brief to be shorter and more concise than the
> FAQ while showing enough to get going.
>
>
> I am quite certain that wording, examples and the references from other
> manuals can be tweaked, but this diff looks like a good enough start
> and --if this is the way to go-- I'd prefer to commit and keep polishing
> in-tree.
>
> Feedback? Objections? OK?
>
>
> Index: distrib/sets/lists/man/mi
> ===
> RCS file: /cvs/src/distrib/sets/lists/man/mi,v
> retrieving revision 1.1643
> diff -u -p -r1.1643 mi
> --- distrib/sets/lists/man/mi 21 Oct 2021 18:36:41 - 1.1643
> +++ distrib/sets/lists/man/mi 27 Oct 2021 20:39:11 -
> @@ -2558,6 +2558,7 @@
> ./usr/share/man/man8/security.8
> ./usr/share/man/man8/sendmail.8
> ./usr/share/man/man8/sensorsd.8
> +./usr/share/man/man8/site.8
> ./usr/share/man/man8/sftp-server.8
> ./usr/share/man/man8/showmount.8
> ./usr/share/man/man8/shutdown.8
> Index: usr.sbin/sysupgrade/sysupgrade.8
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
> retrieving revision 1.10
> diff -u -p -r1.10 sysupgrade.8
> --- usr.sbin/sysupgrade/sysupgrade.8 3 Oct 2019 12:43:58 - 1.10
> +++ usr.sbin/sysupgrade/sysupgrade.8 27 Oct 2021 20:42:26 -
> @@ -67,6 +67,10 @@ This is the default if the system is cur
> Upgrade to a snapshot.
> This is the default if the system is currently running a snapshot.
> .El
> +.Pp
> +See
> +.Xr site 8
> +for how to customize the upgrade process.
> .Sh FILES
> .Bl -tag -width "/auto_upgrade.conf" -compact
> .It Pa /auto_upgrade.conf
> @@ -83,7 +87,8 @@ Directory the upgrade is downloaded to.
> .Xr signify 1 ,
> .Xr installurl 5 ,
> .Xr autoinstall 8 ,
> -.Xr release 8
> +.Xr release 8 ,
> +.Xr site 8
> .Sh HISTORY
> .Nm
> first appeared in
> Index: share/man/man8/Makefile
> ===
> RCS file: /cvs/src/share/man/man8/Makefile,v
> retrieving revision 1.102
> diff -u -p -r1.102 Makefile
> --- share/man/man8/Makefile 1 May 2021 16:11:10 - 1.102
> +++ share/man/man8/Makefile 27 Oct 2021 20:38:11 -
> @@ -6,7 +6,7 @@ MAN= afterboot.8 autoinstall.8 boot_conf
> crash.8 daily.8 \
> diskless.8 genassym.sh.8 intro.8 netstart.8 rc.8 \
> rc.conf.8 rc.d.8 rc.shutdown.8 rc.subr.8 release.8 \
> - security.8 ssl.8 starttls.8 sticky.8 yp.8
> + security.8 site.8 ssl.8 starttls.8 sticky.8 yp.8
>
> SUBDIR= man8.alpha man8.amd64 man8.arm64 man8.armv7 \
> man8.hppa man8.i386 man8.landisk \
> Index: share/man/man8/autoinstall.8
> ===
> RCS file: /cvs/src/share/man/man8/autoinstall.8,v
> retrieving revision 1.23
> diff -u -p -r1.23 autoinstall.8
> --- share/man/man8/autoinstall.8 18 Jul 2021 11:08:34 - 1.23
> +++ share/man/man8/autoinstall.8 27 Oct 2021 20:42:24 -
> @@ -32,6 +32,10 @@ file and HTTP to fetch the file.
> If that fails, the installer asks for the location which can either be
> a URL or a local path.
> .Pp
> +See
> +.Xr site 8
> +for how to provide custom configuration.
> +.Pp
> To start unattended installation or upgrade choose '(A)utoinstall' at the
> install prompt.
> If there is only one network interface, the installer fetches the response
> @@ -235,7 +239,8 @@ host foo {
> .Sh SEE ALSO
> .Xr dhcp-options 5 ,
> .Xr dhcpd.conf 5 ,
> -.Xr diskless 8
> +.Xr diskless 8 ,
> +.Xr site 8
> .Sh HISTORY
> The
> .Nm
> Index: share/man/man8/site.8
> ===
> RCS file: share/man/man8/site.8
> diff -N share/man/man8/site.8
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ share/man/man8/site.8 27 Oct 2021 21:11:48 -
> @@ -0,0 +1,87 @@
> +.\" $OpenBSD: $
> +.\"
> +.\" Copyright (c) 2021 Klemens Nanni
> +.\"
> +.\" Permission to use, copy, modify, and distribute this software for any
> +.\" purpose with or without fee is hereby granted, provided that the above
> +.\" copyright notice and this permission notice appear in all copies.
> +.\"
> +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +.\" WITH REGARD TO THIS SOFTWARE INCLUDING
Re: snmpd(8): don't allocate memory for system mib
On Wed, 27 Oct 2021 21:56:16 +0100, Martijn van Duren wrote:
> Maybe it's not sufficient, but:
>
> sysDescr OBJECT-TYPE
> SYNTAX DisplayString (SIZE (0..255))
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "A textual description of the entity. This value should
> include the full name and version identification of
> the system's hardware type, software operating-system,
> and networking software."
> ::= { system 1 }
Fair enough.
- todd
new site.8: document site*.tgz and /{upgrade,install}.site
On Mon, Sep 06, 2021 at 02:29:50PM -0500, Aaron Poffenberger wrote:
> Ping.
>
> Will someone commit this? Seems like no one knows about /upgrade.site and it
> fits well with sysupgrade(8).
sysupgrade(8) is one potential /upgrade.site user but I disagree about
documenting the latter through the former.
Here is a new manual roughly merging the FAQ bits with what you, Aaron,
provided.
site(8) is a lame but fitting name; autoinstall(8) and sysypgrade(8)
reference it and both sets and scripts are documented.
Examples are intentionally brief to be shorter and more concise than the
FAQ while showing enough to get going.
I am quite certain that wording, examples and the references from other
manuals can be tweaked, but this diff looks like a good enough start
and --if this is the way to go-- I'd prefer to commit and keep polishing
in-tree.
Feedback? Objections? OK?
Index: distrib/sets/lists/man/mi
===
RCS file: /cvs/src/distrib/sets/lists/man/mi,v
retrieving revision 1.1643
diff -u -p -r1.1643 mi
--- distrib/sets/lists/man/mi 21 Oct 2021 18:36:41 - 1.1643
+++ distrib/sets/lists/man/mi 27 Oct 2021 20:39:11 -
@@ -2558,6 +2558,7 @@
./usr/share/man/man8/security.8
./usr/share/man/man8/sendmail.8
./usr/share/man/man8/sensorsd.8
+./usr/share/man/man8/site.8
./usr/share/man/man8/sftp-server.8
./usr/share/man/man8/showmount.8
./usr/share/man/man8/shutdown.8
Index: usr.sbin/sysupgrade/sysupgrade.8
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
retrieving revision 1.10
diff -u -p -r1.10 sysupgrade.8
--- usr.sbin/sysupgrade/sysupgrade.83 Oct 2019 12:43:58 - 1.10
+++ usr.sbin/sysupgrade/sysupgrade.827 Oct 2021 20:42:26 -
@@ -67,6 +67,10 @@ This is the default if the system is cur
Upgrade to a snapshot.
This is the default if the system is currently running a snapshot.
.El
+.Pp
+See
+.Xr site 8
+for how to customize the upgrade process.
.Sh FILES
.Bl -tag -width "/auto_upgrade.conf" -compact
.It Pa /auto_upgrade.conf
@@ -83,7 +87,8 @@ Directory the upgrade is downloaded to.
.Xr signify 1 ,
.Xr installurl 5 ,
.Xr autoinstall 8 ,
-.Xr release 8
+.Xr release 8 ,
+.Xr site 8
.Sh HISTORY
.Nm
first appeared in
Index: share/man/man8/Makefile
===
RCS file: /cvs/src/share/man/man8/Makefile,v
retrieving revision 1.102
diff -u -p -r1.102 Makefile
--- share/man/man8/Makefile 1 May 2021 16:11:10 - 1.102
+++ share/man/man8/Makefile 27 Oct 2021 20:38:11 -
@@ -6,7 +6,7 @@ MAN=afterboot.8 autoinstall.8 boot_conf
crash.8 daily.8 \
diskless.8 genassym.sh.8 intro.8 netstart.8 rc.8 \
rc.conf.8 rc.d.8 rc.shutdown.8 rc.subr.8 release.8 \
- security.8 ssl.8 starttls.8 sticky.8 yp.8
+ security.8 site.8 ssl.8 starttls.8 sticky.8 yp.8
SUBDIR=man8.alpha man8.amd64 man8.arm64 man8.armv7 \
man8.hppa man8.i386 man8.landisk \
Index: share/man/man8/autoinstall.8
===
RCS file: /cvs/src/share/man/man8/autoinstall.8,v
retrieving revision 1.23
diff -u -p -r1.23 autoinstall.8
--- share/man/man8/autoinstall.818 Jul 2021 11:08:34 - 1.23
+++ share/man/man8/autoinstall.827 Oct 2021 20:42:24 -
@@ -32,6 +32,10 @@ file and HTTP to fetch the file.
If that fails, the installer asks for the location which can either be
a URL or a local path.
.Pp
+See
+.Xr site 8
+for how to provide custom configuration.
+.Pp
To start unattended installation or upgrade choose '(A)utoinstall' at the
install prompt.
If there is only one network interface, the installer fetches the response
@@ -235,7 +239,8 @@ host foo {
.Sh SEE ALSO
.Xr dhcp-options 5 ,
.Xr dhcpd.conf 5 ,
-.Xr diskless 8
+.Xr diskless 8 ,
+.Xr site 8
.Sh HISTORY
The
.Nm
Index: share/man/man8/site.8
===
RCS file: share/man/man8/site.8
diff -N share/man/man8/site.8
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man8/site.8 27 Oct 2021 21:11:48 -
@@ -0,0 +1,87 @@
+.\" $OpenBSD: $
+.\"
+.\" Copyright (c) 2021 Klemens Nanni
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
Re: snmpd(8): don't allocate memory for system mib
On Wed, 2021-10-27 at 14:14 -0600, Todd C. Miller wrote:
> On Wed, 27 Oct 2021 17:14:28 +0100, Martijn van Duren wrote:
>
> > Trying to search for memory leaks in my new snmpd code I found some
> > harmless, but annoying ones in system from SNMPv2-MIB.
> >
> > We call uname(3) every time (even if we don't even need info from
> > that call) and ones set we save it until forever.
> >
> > Diff below calls uname(3) only a single time and if the variables
> > aren't snmpd.conf I simply rebuild it every time.
>
> It's possible that 256 bytes will not be sufficient. I think you
> need to make the buffer sizeof(struct utsname) bytes.
>
> - todd
Maybe it's not sufficient, but:
sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the entity. This value should
include the full name and version identification of
the system's hardware type, software operating-system,
and networking software."
::= { system 1 }
Re: snmpd(8): don't allocate memory for system mib
On Wed, 27 Oct 2021 17:14:28 +0100, Martijn van Duren wrote: > Trying to search for memory leaks in my new snmpd code I found some > harmless, but annoying ones in system from SNMPv2-MIB. > > We call uname(3) every time (even if we don't even need info from > that call) and ones set we save it until forever. > > Diff below calls uname(3) only a single time and if the variables > aren't snmpd.conf I simply rebuild it every time. It's possible that 256 bytes will not be sufficient. I think you need to make the buffer sizeof(struct utsname) bytes. - todd
Re: demystify vport(4) in vport(4) and ifconfig(8)
On Wed, 27 Oct 2021 14:32:31 +0100 Jason McIntyre : > 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 agree about ifconfig(8), if it's incomplete this is more misleading than helping, and hints in the devices man pages about using ifconfig/hostname.if are a very helpful and won't rot.
Re: snmpd(8): don't allocate memory for system mib
On Wed, 2021-10-27 at 17:37 +0100, Stuart Henderson wrote:
> On 2021/10/27 17:14, Martijn van Duren wrote:
> > Trying to search for memory leaks in my new snmpd code I found some
> > harmless, but annoying ones in system from SNMPv2-MIB.
> >
> > We call uname(3) every time (even if we don't even need info from
> > that call) and ones set we save it until forever.
> >
> > Diff below calls uname(3) only a single time and if the variables
> > aren't snmpd.conf I simply rebuild it every time.
>
> I'm in two minds about this. While it's not something that will happen
> very often, hostnames do get changed sometimes, and it would be nice to
> have snmpd reflect the current name of the system rather than what it
> was named when snmpd started.
But that's the fun part, as soon as it has been requested ones it
continues to being cached anyway, so calling uname(3) every time
is completely useless.
Even better, it may result in inconsistency between objects:
test1$ snmp get -v2c -cpublic 127.0.0.1 sysdescr.0
sysDescr.0 = STRING: OpenBSD test1 7.0 GENERIC.MP#42 amd64
test1$ doas hostname test2
test2$ snmp get -v2c -cpublic 127.0.0.1 sysname.0
sysName.0 = STRING: test2
test2$ snmp get -v2c -cpublic 127.0.0.1 sysdescr.0
sysDescr.0 = STRING: OpenBSD test1 7.0 GENERIC.MP#42 amd64
We can go for what you're describing, but I'm not sure it's
worth it. Whatever you think is best :-)
>
> > I also changed the default "system contact" to an empty string,
> > since SNMPv2-MIB states:
> > "If no contact information is known, the value is the zero-length
> > string."
> > I've basically never came across a system where there was both
> > a smtp process accepting remote mail for the root-account and
> > where the hostname were correctly resolving. If people are really
> > attached to this value it's easy enough to set it, but I think
> > it would be better to not tell unfounded assertions.
>
> I'm certainly OK with that part.
>
> > OK?
> >
> > martijn@
> >
> > Index: mib.c
> > ===
> > RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
> > retrieving revision 1.102
> > diff -u -p -r1.102 mib.c
> > --- mib.c 1 Sep 2021 15:54:40 - 1.102
> > +++ mib.c 27 Oct 2021 16:14:15 -
> > @@ -126,22 +126,25 @@ mib_getsys(struct oid *oid, struct ber_o
> > {
> > struct ber_oid sysoid = OID(MIB_SYSOID_DEFAULT);
> > char*s = oid->o_data;
> > + char buf[256];
> > struct ber_oid *so = oid->o_data;
> > - struct utsname u;
> > + static struct utsnameu;
> > + int init = 0;
> > long longticks;
> >
> > - if (uname() == -1)
> > - return (-1);
> > + if (!init) {
> > + if (uname() == -1)
> > + return (-1);
> > + init = 1;
> > + }
> >
> > switch (oid->o_oid[OIDIDX_system]) {
> > case 1:
> > if (s == NULL) {
> > - if (asprintf(, "%s %s %s %s %s",
> > + snprintf(buf, sizeof(buf), "%s %s %s %s %s",
> > u.sysname, u.nodename, u.release,
> > - u.version, u.machine) == -1)
> > - return (-1);
> > - oid->o_data = s;
> > - oid->o_val = strlen(s);
> > + u.version, u.machine);
> > + s = buf;
> > }
> > *elm = ober_add_string(*elm, s);
> > break;
> > @@ -157,21 +160,13 @@ mib_getsys(struct oid *oid, struct ber_o
> > ober_set_header(*elm, BER_CLASS_APPLICATION, SNMP_T_TIMETICKS);
> > break;
> > case 4:
> > - if (s == NULL) {
> > - if (asprintf(, "root@%s", u.nodename) == -1)
> > - return (-1);
> > - oid->o_data = s;
> > - oid->o_val = strlen(s);
> > - }
> > + if (s == NULL)
> > + s = "";
> > *elm = ober_add_string(*elm, s);
> > break;
> > case 5:
> > - if (s == NULL) {
> > - if ((s = strdup(u.nodename)) == NULL)
> > - return (-1);
> > - oid->o_data = s;
> > - oid->o_val = strlen(s);
> > - }
> > + if (s == NULL)
> > + s = u.nodename;
> > *elm = ober_add_string(*elm, s);
> > break;
> > case 6:
> > Index: snmpd.conf.5
> > ===
> > RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
> > retrieving revision 1.58
> > diff -u -p -r1.58 snmpd.conf.5
> > --- snmpd.conf.52 Sep 2021 05:41:02 - 1.58
> > +++ snmpd.conf.527 Oct 2021 16:14:15 -
> > @@ -244,9 +244,6 @@ This is the default value.
> > .It Ic system contact Ar string
> > Specify
Re: snmpd(8): don't allocate memory for system mib
On 2021/10/27 17:14, Martijn van Duren wrote:
> Trying to search for memory leaks in my new snmpd code I found some
> harmless, but annoying ones in system from SNMPv2-MIB.
>
> We call uname(3) every time (even if we don't even need info from
> that call) and ones set we save it until forever.
>
> Diff below calls uname(3) only a single time and if the variables
> aren't snmpd.conf I simply rebuild it every time.
I'm in two minds about this. While it's not something that will happen
very often, hostnames do get changed sometimes, and it would be nice to
have snmpd reflect the current name of the system rather than what it
was named when snmpd started.
> I also changed the default "system contact" to an empty string,
> since SNMPv2-MIB states:
> "If no contact information is known, the value is the zero-length
> string."
> I've basically never came across a system where there was both
> a smtp process accepting remote mail for the root-account and
> where the hostname were correctly resolving. If people are really
> attached to this value it's easy enough to set it, but I think
> it would be better to not tell unfounded assertions.
I'm certainly OK with that part.
> OK?
>
> martijn@
>
> Index: mib.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
> retrieving revision 1.102
> diff -u -p -r1.102 mib.c
> --- mib.c 1 Sep 2021 15:54:40 - 1.102
> +++ mib.c 27 Oct 2021 16:14:15 -
> @@ -126,22 +126,25 @@ mib_getsys(struct oid *oid, struct ber_o
> {
> struct ber_oid sysoid = OID(MIB_SYSOID_DEFAULT);
> char*s = oid->o_data;
> + char buf[256];
> struct ber_oid *so = oid->o_data;
> - struct utsname u;
> + static struct utsnameu;
> + int init = 0;
> long longticks;
>
> - if (uname() == -1)
> - return (-1);
> + if (!init) {
> + if (uname() == -1)
> + return (-1);
> + init = 1;
> + }
>
> switch (oid->o_oid[OIDIDX_system]) {
> case 1:
> if (s == NULL) {
> - if (asprintf(, "%s %s %s %s %s",
> + snprintf(buf, sizeof(buf), "%s %s %s %s %s",
> u.sysname, u.nodename, u.release,
> - u.version, u.machine) == -1)
> - return (-1);
> - oid->o_data = s;
> - oid->o_val = strlen(s);
> + u.version, u.machine);
> + s = buf;
> }
> *elm = ober_add_string(*elm, s);
> break;
> @@ -157,21 +160,13 @@ mib_getsys(struct oid *oid, struct ber_o
> ober_set_header(*elm, BER_CLASS_APPLICATION, SNMP_T_TIMETICKS);
> break;
> case 4:
> - if (s == NULL) {
> - if (asprintf(, "root@%s", u.nodename) == -1)
> - return (-1);
> - oid->o_data = s;
> - oid->o_val = strlen(s);
> - }
> + if (s == NULL)
> + s = "";
> *elm = ober_add_string(*elm, s);
> break;
> case 5:
> - if (s == NULL) {
> - if ((s = strdup(u.nodename)) == NULL)
> - return (-1);
> - oid->o_data = s;
> - oid->o_val = strlen(s);
> - }
> + if (s == NULL)
> + s = u.nodename;
> *elm = ober_add_string(*elm, s);
> break;
> case 6:
> Index: snmpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
> retrieving revision 1.58
> diff -u -p -r1.58 snmpd.conf.5
> --- snmpd.conf.5 2 Sep 2021 05:41:02 - 1.58
> +++ snmpd.conf.5 27 Oct 2021 16:14:15 -
> @@ -244,9 +244,6 @@ This is the default value.
> .It Ic system contact Ar string
> Specify the name or description of the system contact, typically a
> name or an email address.
> -The default value is
> -.Ar root@hostname
> -using the hostname of the local machine.
> .It Ic system description Ar string
> Specify a description of the local system.
> The default value is the operating system identification as printed by the
>
>
snmpd(8): don't allocate memory for system mib
Trying to search for memory leaks in my new snmpd code I found some
harmless, but annoying ones in system from SNMPv2-MIB.
We call uname(3) every time (even if we don't even need info from
that call) and ones set we save it until forever.
Diff below calls uname(3) only a single time and if the variables
aren't snmpd.conf I simply rebuild it every time.
I also changed the default "system contact" to an empty string,
since SNMPv2-MIB states:
"If no contact information is known, the value is the zero-length
string."
I've basically never came across a system where there was both
a smtp process accepting remote mail for the root-account and
where the hostname were correctly resolving. If people are really
attached to this value it's easy enough to set it, but I think
it would be better to not tell unfounded assertions.
OK?
martijn@
Index: mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.102
diff -u -p -r1.102 mib.c
--- mib.c 1 Sep 2021 15:54:40 - 1.102
+++ mib.c 27 Oct 2021 16:14:15 -
@@ -126,22 +126,25 @@ mib_getsys(struct oid *oid, struct ber_o
{
struct ber_oid sysoid = OID(MIB_SYSOID_DEFAULT);
char*s = oid->o_data;
+ char buf[256];
struct ber_oid *so = oid->o_data;
- struct utsname u;
+ static struct utsnameu;
+ int init = 0;
long longticks;
- if (uname() == -1)
- return (-1);
+ if (!init) {
+ if (uname() == -1)
+ return (-1);
+ init = 1;
+ }
switch (oid->o_oid[OIDIDX_system]) {
case 1:
if (s == NULL) {
- if (asprintf(, "%s %s %s %s %s",
+ snprintf(buf, sizeof(buf), "%s %s %s %s %s",
u.sysname, u.nodename, u.release,
- u.version, u.machine) == -1)
- return (-1);
- oid->o_data = s;
- oid->o_val = strlen(s);
+ u.version, u.machine);
+ s = buf;
}
*elm = ober_add_string(*elm, s);
break;
@@ -157,21 +160,13 @@ mib_getsys(struct oid *oid, struct ber_o
ober_set_header(*elm, BER_CLASS_APPLICATION, SNMP_T_TIMETICKS);
break;
case 4:
- if (s == NULL) {
- if (asprintf(, "root@%s", u.nodename) == -1)
- return (-1);
- oid->o_data = s;
- oid->o_val = strlen(s);
- }
+ if (s == NULL)
+ s = "";
*elm = ober_add_string(*elm, s);
break;
case 5:
- if (s == NULL) {
- if ((s = strdup(u.nodename)) == NULL)
- return (-1);
- oid->o_data = s;
- oid->o_val = strlen(s);
- }
+ if (s == NULL)
+ s = u.nodename;
*elm = ober_add_string(*elm, s);
break;
case 6:
Index: snmpd.conf.5
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
retrieving revision 1.58
diff -u -p -r1.58 snmpd.conf.5
--- snmpd.conf.52 Sep 2021 05:41:02 - 1.58
+++ snmpd.conf.527 Oct 2021 16:14:15 -
@@ -244,9 +244,6 @@ This is the default value.
.It Ic system contact Ar string
Specify the name or description of the system contact, typically a
name or an email address.
-The default value is
-.Ar root@hostname
-using the hostname of the local machine.
.It Ic system description Ar string
Specify a description of the local system.
The default value is the operating system identification as printed by the
Re: demystify vport(4) in vport(4) and ifconfig(8)
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 - 1.2 > +++ veb.4 27 Oct 2021 09:03:49 - > @@ -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 >
Re: demystify vport(4) in vport(4) and ifconfig(8)
On Wed, 27 Oct 2021 07:28:32 +1000 David Gwynne : > On Tue, Oct 26, 2021 at 09:18:30PM +0200, Solene Rapenne wrote: > > I tried to figure out how to use veb interfaces but the man page > > wasn't obvious in regards to the "vport" thing. It turns out it's > > a kind of interface that can be created with ifconfig. > > > > I think we should make this clearer. > > agreed. the man page for veb/vport is definitely not... rigorous. > > > Because ifconfig(8) mentions many type of interfaces I've searched > > for "vport" without success while "most" types are referenced in > > the man page. Like I added veb(4) recently, the diff adds vport(4) > > and missing mpip(4) so a search would give a clue it's related to > > ifconfig. > > I'm ok with the ifconfig chunk. > > > in veb(4), I think we should add vport in the synposis because the > > man page is shared for veb and vport interfaces but at first look > > it seems only veb is a type of interface. > > The synopsis shows what you put into a kernel config file (eg > src/sys/conf/GENERIC) to enable the driver, but "pseudo-device > vport" is not valid kernel config. You enable the veb driver and that > one driver provides both veb and vport interfaces. Another example of > this is the gre driver which provides gre, egre, mgre, nvgre, and eoip > interfaces. > > > And finally, I added a mention that vport can be created with > > ifconfig(8) so it's really obvious. Maybe it's too much and can be > > removed. > > It should definitely be said. The other man pages for clonable > interfaces generally have a paragraph like this: > > .Nm gre , > .Nm mgre , > .Nm egre , > and > .Nm nvgre > interfaces can be created at runtime using the > .Ic ifconfig iface Ns Ar N Ic create > command or by setting up a > .Xr hostname.if 5 > configuration file for > .Xr netstart 8 . > > I just noticed vether.4 is also missing a paragraph like that too :( > > > comments? ok? > > Apart from it not being obvious where vport interfaces come from, is > there anything else not obvious about veb? > veb is fine to me, here is a diff that adds the ifconfig paragraph to veb(4) and vether(4), I removed my first change from veb. 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). Index: share/man/man4//veb.4 === RCS file: /home/reposync/src/share/man/man4/veb.4,v retrieving revision 1.2 diff -u -p -r1.2 veb.4 --- share/man/man4//veb.4 23 Feb 2021 11:43:41 - 1.2 +++ share/man/man4//veb.4 27 Oct 2021 06:28:45 - @@ -43,6 +43,17 @@ From the perspective of the host network interface acts as a normal interface connected to an Ethernet network. .Pp +A +.Nm veb +or +.Nm vport +interface can be created at runtime using the +.Ic ifconfig iface Ns Ar N Ic create +command or by setting up a +.Xr hostname.if 5 +configuration file for +.Xr netstart 8 . +.Pp .Nm veb is a learning bridge that maintains a table of Ethernet addresses and the port that each address is reachable with. Index: share/man/man4//vether.4 === RCS file: /home/reposync/src/share/man/man4/vether.4,v retrieving revision 1.5 diff -u -p -r1.5 vether.4 --- share/man/man4//vether.417 Oct 2017 22:47:58 - 1.5 +++ share/man/man4//vether.427 Oct 2021 06:29:54 - @@ -30,6 +30,15 @@ standard network frames with an Ethernet for use as a member in a .Xr bridge 4 . .Pp +A +.Nm +interface can be created at runtime using the +.Ic ifconfig vether Ns Ar N Ic create +command or by setting up a +.Xr hostname.if 5 +configuration file for +.Xr netstart 8 . +.Pp To use .Nm the administrator needs to configure an address onto the interface
Re: demystify vport(4) in vport(4) and ifconfig(8)
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. 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 - 1.2 +++ veb.4 27 Oct 2021 09:03:49 - @@ -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
Re: demystify vport(4) in vport(4) and ifconfig(8)
On Wed, Oct 27, 2021 at 08:34:48AM +0200, Solene Rapenne wrote: > On Wed, 27 Oct 2021 07:28:32 +1000 > David Gwynne : > > > On Tue, Oct 26, 2021 at 09:18:30PM +0200, Solene Rapenne wrote: > > > I tried to figure out how to use veb interfaces but the man page > > > wasn't obvious in regards to the "vport" thing. It turns out it's > > > a kind of interface that can be created with ifconfig. > > > > > > I think we should make this clearer. > > > > agreed. the man page for veb/vport is definitely not... rigorous. > > > > > Because ifconfig(8) mentions many type of interfaces I've searched > > > for "vport" without success while "most" types are referenced in > > > the man page. Like I added veb(4) recently, the diff adds vport(4) > > > and missing mpip(4) so a search would give a clue it's related to > > > ifconfig. > > > > I'm ok with the ifconfig chunk. > > > > > in veb(4), I think we should add vport in the synposis because the > > > man page is shared for veb and vport interfaces but at first look > > > it seems only veb is a type of interface. > > > > The synopsis shows what you put into a kernel config file (eg > > src/sys/conf/GENERIC) to enable the driver, but "pseudo-device > > vport" is not valid kernel config. You enable the veb driver and that > > one driver provides both veb and vport interfaces. Another example of > > this is the gre driver which provides gre, egre, mgre, nvgre, and eoip > > interfaces. > > > > > And finally, I added a mention that vport can be created with > > > ifconfig(8) so it's really obvious. Maybe it's too much and can be > > > removed. > > > > It should definitely be said. The other man pages for clonable > > interfaces generally have a paragraph like this: > > > > .Nm gre , > > .Nm mgre , > > .Nm egre , > > and > > .Nm nvgre > > interfaces can be created at runtime using the > > .Ic ifconfig iface Ns Ar N Ic create > > command or by setting up a > > .Xr hostname.if 5 > > configuration file for > > .Xr netstart 8 . > > > > I just noticed vether.4 is also missing a paragraph like that too :( > > > > > comments? ok? > > > > Apart from it not being obvious where vport interfaces come from, is > > there anything else not obvious about veb? > > > > veb is fine to me, here is a diff that adds the ifconfig paragraph > to veb(4) and vether(4), I removed my first change from veb. ok by me. > 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? > Index: share/man/man4//veb.4 > === > RCS file: /home/reposync/src/share/man/man4/veb.4,v > retrieving revision 1.2 > diff -u -p -r1.2 veb.4 > --- share/man/man4//veb.4 23 Feb 2021 11:43:41 - 1.2 > +++ share/man/man4//veb.4 27 Oct 2021 06:28:45 - > @@ -43,6 +43,17 @@ From the perspective of the host network > interface acts as a normal interface connected to an Ethernet > network. > .Pp > +A > +.Nm veb > +or > +.Nm vport > +interface can be created at runtime using the > +.Ic ifconfig iface Ns Ar N Ic create > +command or by setting up a > +.Xr hostname.if 5 > +configuration file for > +.Xr netstart 8 . > +.Pp > .Nm veb > is a learning bridge that maintains a table of Ethernet addresses > and the port that each address is reachable with. > Index: share/man/man4//vether.4 > === > RCS file: /home/reposync/src/share/man/man4/vether.4,v > retrieving revision 1.5 > diff -u -p -r1.5 vether.4 > --- share/man/man4//vether.4 17 Oct 2017 22:47:58 - 1.5 > +++ share/man/man4//vether.4 27 Oct 2021 06:29:54 - > @@ -30,6 +30,15 @@ standard network frames with an Ethernet > for use as a member in a > .Xr bridge 4 . > .Pp > +A > +.Nm > +interface can be created at runtime using the > +.Ic ifconfig vether Ns Ar N Ic create > +command or by setting up a > +.Xr hostname.if 5 > +configuration file for > +.Xr netstart 8 . > +.Pp > To use > .Nm > the administrator needs to configure an address onto the interface
Re: [External] : soqinsque(): replace 'DIAGNOSTIC' block by KASSERT(9)
On Tue, Oct 26, 2021 at 11:55:23PM +0300, Vitaliy Makkoveev wrote:
> Just for consistency with the rest of kern/uipc_socket2.c
looks OK to me.
sashan
>
> Index: sys/kern/uipc_socket2.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
> retrieving revision 1.113
> diff -u -p -r1.113 uipc_socket2.c
> --- sys/kern/uipc_socket2.c 26 Jul 2021 05:51:13 - 1.113
> +++ sys/kern/uipc_socket2.c 26 Oct 2021 20:49:51 -
> @@ -212,10 +212,7 @@ soqinsque(struct socket *head, struct so
> {
> soassertlocked(head);
>
> -#ifdef DIAGNOSTIC
> - if (so->so_onq != NULL)
> - panic("soqinsque");
> -#endif
> + KASSERT(so->so_onq == NULL);
>
> so->so_head = head;
> if (q == 0) {
>
