Re: svn commit: r228990 - in head/usr.sbin: IPXrouted adduser bluetooth/btpand bluetooth/sdpd bootparamd/bootparamd bsnmpd/modules/snmp_bridge bsnmpd/modules/snmp_hostres bsnmpd/modules/snmp_wlan bsnm
On Fri, 30 Dec 2011, Ben Kaduk wrote: BK>On Fri, Dec 30, 2011 at 5:58 AM, Ulrich Spoerlein wrote: BK>> Author: uqs BK>> Date: Fri Dec 30 10:58:14 2011 BK>> New Revision: 228990 BK>> URL: http://svn.freebsd.org/changeset/base/228990 BK>> BK>> Log: BK>> Spelling fixes for usr.sbin/ BK>> [snip] BK>> Modified: head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt BK>> == BK>> --- head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt Fri Dec 30 10:45:00 2011 (r228989) BK>> +++ head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt Fri Dec 30 10:58:14 2011 (r228990) BK>> @@ -82,8 +82,8 @@ WlanMgmtReasonCode ::= TEXTUAL-CONVENTIO BK>> associationLeave(8), BK>> associationNotAuthenticated(9), BK>> -- XXX: TODO - FIXME BK>> - dissasocPwrcapBad(10), BK>> - dissasocSuperchanBad(11), BK>> + disassocPwrcapBad(10), BK>> + disassocSuperchanBad(11), BK> BK>This file looks like it might be intended to be machine-readable -- I BK>would worry about changing it without test/review. BK>Perhaps this spelling "error" is even the reason for the XXX comment above. Absolutely. If there is a spelling error in an SNMP MIB outside comments or description strings it must stay there. Otherwise applications reading that file will break. This is also true for the corresponding .def file. harti___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r228990 - in head/usr.sbin: IPXrouted adduser bluetooth/btpand bluetooth/sdpd bootparamd/bootparamd bsnmpd/modules/snmp_bridge bsnmpd/modules/snmp_hostres bsnmpd/modules/snmp_wlan bsnm
Hi Uli, On Sun, 1 Jan 2012, Ulrich Spoerlein wrote: US>Sorry for the delay. US> US>On Fri, 2011-12-30 at 20:50:16 +0100, Harti Brandt wrote: US>> On Fri, 30 Dec 2011, Ben Kaduk wrote: US>> >On Fri, Dec 30, 2011 at 5:58 AM, Ulrich Spoerlein wrote: US>> >> Modified: head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt US>> >> == US>> >> --- head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt Fri Dec 30 10:45:00 2011 (r228989) US>> >> +++ head/usr.sbin/bsnmpd/modules/snmp_wlan/BEGEMOT-WIRELESS-MIB.txt Fri Dec 30 10:58:14 2011 (r228990) US>> >> @@ -82,8 +82,8 @@ WlanMgmtReasonCode ::= TEXTUAL-CONVENTIO US>> >> associationLeave(8), US>> >> associationNotAuthenticated(9), US>> >> -- XXX: TODO - FIXME US>> >> - dissasocPwrcapBad(10), US>> >> - dissasocSuperchanBad(11), US>> >> + disassocPwrcapBad(10), US>> >> + disassocSuperchanBad(11), US>> > US>> >This file looks like it might be intended to be machine-readable -- I US>> >would worry about changing it without test/review. US>> >Perhaps this spelling "error" is even the reason for the XXX comment above. US>> US>> Absolutely. If there is a spelling error in an SNMP MIB outside comments US>> or description strings it must stay there. Otherwise applications reading US>> that file will break. US>> US>> This is also true for the corresponding .def file. US>> US>> harti US> US>Neither Google, Bing nor Google Code Search can find any occurrence of US>any of the two words in either spelling, except in our tree, of course. US>This leads me to believe that at least no known Open Source project will US>be affected by the change. But that doesn't say much. US> US>Is this a non-backwards compatible change that we can do when going from US>9.x to 10.0? I'm fine with backing it out, too, if you think this will US>actually break anything for third parties. Just say the word. Actually there are several RFCs which contain descriptions on doing MIB revisions: RFC 2578, RFC 2579 and RFC 4181. There may be others. 4181 contains the following text: "RFC 2579 Section 5 specifies rules that apply to revisions of textual convention definitions. The following guideline corrects an error in these rules: - Bullet (1) allows the labels of named numbers and named bits in SYNTAX clauses of type enumerated INTEGER or BITS to be changed. This can break compilation compatibility, since those labels may be used by DEFVAL clauses in modules that import the definitions of the affected TCs. Therefore, labels of named numbers and named bits MUST NOT be changed when revising IETF MIB modules (except to correct typographical errors), and they SHOULD NOT be changed when revising enterprise MIB modules." So for the given MIB the term "SHOULD NOT" applies. What I would do is: - keep the misspelled definitions and mark them with a comment as deprecated (unfortunately one can formally deprecate MIB objects, but not integer names). - add correctly spelled definitions - in any case add a revision statement to the MODULE-TYPE macro. Even if you find no open source uses of the MIB, there may be internal uses in companies. I have a number of MIB modules that use FreeBSD modules (albeit not the WLAN module) that are not intended to be released outside our institute because they are quite special-purpose and not of use for somebody else. Nevertheless I would try to not break this kind of use. harti___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r202070 - head/usr.bin/make
Hi,
On Mon, 11 Jan 2010, Andrey Chernov wrote:
AC>On Mon, Jan 11, 2010 at 09:16:42AM +, Hartmut Brandt wrote:
AC>> @@ -1807,8 +1807,6 @@ JobStart(GNode *gn, int flags, Job *prev
AC>>} else {
AC>>fprintf(stdout, "Remaking `%s'\n", gn->name);
AC>>fflush(stdout);
AC>> - if ((tdir = getenv("TMPDIR")) == NULL)
AC>> - tdir = TMPDIR;
AC>>snprintf(job->outFile, sizeof(job->outFile), "%s/%s",
AC>>tdir, TMPPAT);
AC>>if ((job->outFd = mkstemp(job->outFile)) == -1)
AC>
AC>With the presence of .EXPORTVAR directive (setenv() called) TMPDIR
AC>environment can be changed on the fly, so perhaps this lines are for reason.
There is the same getenv() just a couple of lines above of all the if()s
so that it covers both uses of tdir. I just though that doing the getenv()
in both places is slightly more performing that do it all the time. But
decided that this gain would be clearly below noise level. The I forgot to
remove the now unneeded second getenv.
harti
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345797 - in head: contrib/bsnmp/gensnmptree contrib/bsnmp/lib contrib/bsnmp/snmpd lib/libbsnmp/libbsnmp usr.sbin/bsnmpd/bsnmpd
On Tue, 2 Apr 2019, Baptiste Daroussin wrote: BD>On Tue, Apr 02, 2019 at 12:50:01PM +, Andrey V. Elsukov wrote: BD>> Author: ae BD>> Date: Tue Apr 2 12:50:01 2019 BD>> New Revision: 345797 BD>> URL: https://svnweb.freebsd.org/changeset/base/345797 BD>> BD>> Log: BD>> Add IPv6 transport for bsnmp. BD>> BD>> This patch adds a new table begemotSnmpdTransInetTable that uses the BD>> InetAddressType textual convention and can be used to create listening BD>> ports for IPv4, IPv6, zoned IPv6 and based on DNS names. It also supports BD>> future extension beyond UDP by adding a protocol identifier to the table BD>> index. In order to support this gensnmptree had to be modified. BD>> BD>> Submitted by: harti BD>> MFC after: 1 month BD>> Relnotes: yes BD>> Differential Revision: https://reviews.freebsd.org/D16654 BD>> BD>Jumping in this commit, maybe it is time to move bsnmpd out of contrib, given BD>that all the dev appears to only be in our own source tree right? Actually I have a private tree that has some more stuff in it than there is in the contrib tree in FreeBSD. I usually do modifications first in that tree, then I bring it to FreeBSD. If somebody commits modifications to FreeBSD I feed that back. One day I intend to put this into a public place. harti ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345797 - in head: contrib/bsnmp/gensnmptree contrib/bsnmp/lib contrib/bsnmp/snmpd lib/libbsnmp/libbsnmp usr.sbin/bsnmpd/bsnmpd
On Tue, 2 Apr 2019, Baptiste Daroussin wrote: BD>On Tue, Apr 02, 2019 at 12:50:01PM +, Andrey V. Elsukov wrote: BD>> Author: ae BD>> Date: Tue Apr 2 12:50:01 2019 BD>> New Revision: 345797 BD>> URL: https://svnweb.freebsd.org/changeset/base/345797 BD>> BD>> Log: BD>> Add IPv6 transport for bsnmp. BD>> BD>> This patch adds a new table begemotSnmpdTransInetTable that uses the BD>> InetAddressType textual convention and can be used to create listening BD>> ports for IPv4, IPv6, zoned IPv6 and based on DNS names. It also supports BD>> future extension beyond UDP by adding a protocol identifier to the table BD>> index. In order to support this gensnmptree had to be modified. BD>> BD>> Submitted by: harti BD>> MFC after: 1 month BD>> Relnotes: yes BD>> Differential Revision: https://reviews.freebsd.org/D16654 BD>> BD>Jumping in this commit, maybe it is time to move bsnmpd out of contrib, given BD>that all the dev appears to only be in our own source tree right? Actually I have a private tree that has some more stuff in it than there is in the contrib tree in FreeBSD. I usually do modifications first in that tree, then I bring it to FreeBSD. If somebody commits modifications to FreeBSD I feed that back. One day I intend to put this into a public place. harti ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
