Re: diff: isakmpd.conf.5, clarify ANY can be used for some params

On Tue, Nov 02, 2021 at 12:04:25PM +0900, YASUOKA Masahiko wrote: > ok? > > Clarify that ANY can be used for several parameters of IPsec transform. > > Index: sbin/isakmpd/isakmpd.conf.5 > === > RCS file: /cvs/src/sbin/isakmpd/isakmp

tr(1): next(): simplify NORMAL case

The NORMAL case code in next() is needlessly complicated. The switch statement in particular is about as creative as it can possibly be. Isolate the early-return cases (end-of-string, bracket) from the could-be-a-range cases (backslash, any other character). Slightly less optimized, far simpler

diff: isakmpd.conf.5, clarify ANY can be used for some params

ok? Clarify that ANY can be used for several parameters of IPsec transform. Index: sbin/isakmpd/isakmpd.conf.5 === RCS file: /cvs/src/sbin/isakmpd/isakmpd.conf.5,v retrieving revision 1.135 diff -u -p -r1.135 isakmpd.conf.5 --- sbin/

diff: ipsec.conf(5), clarify "aes" accepts 128:256 bits

I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits. sbin/ipsecctl/ike.c: 201 case ENCXF_AES: 202 enc_alg = "AES"; 203 key_length = "128,128:256"; 204 br

Re: uniq(1): ignore newline when comparing lines?

On Mon, Nov 01, 2021 at 07:33:58PM -0600, Todd C. Miller wrote: > On Mon, 01 Nov 2021 20:20:49 -0500, Scott Cheloha wrote: > > > On the one hand, it is intuitive that two buffers are not literally > > the same if one has a newline and the other does not. strcmp(3) > > agrees with this. > > > > ..

Re: uniq(1): ignore newline when comparing lines?

On Mon, 01 Nov 2021 20:20:49 -0500, Scott Cheloha wrote: > On the one hand, it is intuitive that two buffers are not literally > the same if one has a newline and the other does not. strcmp(3) > agrees with this. > > ... On the other hand, it also seems intuitive that two records are > the same e

uniq(1): ignore newline when comparing lines?

POSIX.1-2008 added a new sentence to the description of uniq: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uniq.html > [...] The trailing of each line in the input shall be > ignored when doing comparisons. It comes from this interpretation: https://collaboration.opengroup.org/au

Re: Is getpass(3) really obsolete?

On Sat, 30 Oct 2021, Alejandro Colomar (man-pages) via Libc-alpha wrote: > > See the discussion of deprecation starting with > > (C2X > > has also deprecated those functions). The comments in that thread > > supported marking the

Re: uniq(1): support arbitrarily long lines

On Mon, Nov 01, 2021 at 10:27:40AM -0600, Todd C. Miller wrote: > On Mon, 01 Nov 2021 10:36:08 -0500, Scott Cheloha wrote: > > > My own testing here with pathological inputs didn't show that large of > > a performance difference between fgets(3) and getline(3). There was > > a difference but it w

Re: snmpd(8): New application layer - step towards agentx support

On Mon, 2021-11-01 at 18:59 +0100, Martijn van Duren wrote: > So here's (part of) my work from h2k21. > And here's the diff to make regress pass again. Index: usr.bin/snmp/Makefile === RCS file: /cvs/src/regress/usr.bin/snmp/Makefile

snmpd(8): New application layer - step towards agentx support

So here's (part of) my work from h2k21. The end-goal is to re-introduce agentx support in snmpd. Currently snmpd(8) has its varbind logic divided over 4 files: - snmpe.c: loop over the varbinds inside the pdu/snmp-package. - smi.c:Register all the objects and act as a lookup for the

Re: uniq(1): support arbitrarily long lines

On 2021/11/01 10:36, Scott Cheloha wrote: > How did you generate this input? Is it just ten million lines with a > single 'z' character? `jot -bz 1000`? That one was lots of copies of ports/infrastructure/bsd.port.mk catted together. > Updated patch. > > I screwed up. We don't need to fre

Re: uniq(1): support arbitrarily long lines

On Mon, 01 Nov 2021 10:36:08 -0500, Scott Cheloha wrote: > My own testing here with pathological inputs didn't show that large of > a performance difference between fgets(3) and getline(3). There was > a difference but it was closer to like 5-10%. With your updated patch I see: % wc -l /tmp/z

Re: tr(1): plug leak in genclass()

On Sun, 31 Oct 2021 17:28:55 -0500, Scott Cheloha wrote: > In tr(1), if we have already generated a given character class we > don't need to do it again. OK. > Further, we don't need to keep all the memory we allocate for the set > of characters in the class. NCHARS + 1 is just an upper bound on

Re: uniq(1): support arbitrarily long lines

On Mon, Nov 01, 2021 at 09:04:03AM +, Stuart Henderson wrote: > On 2021/10/31 20:48, Scott Cheloha wrote: > > In uniq(1), if we use getline(3) instead of fgets(3) we can support > > arbitrarily long lines. > > It works for me, and getting rid of the length restriction is nice. > > I don't kno

Re: add 802.11n 40MHz support to iwn(4)

On Mon, Nov 01, 2021 at 01:05:22PM +0100, Stefan Sperling wrote: > On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote: > > To check whether your access point uses a 40MHz channel, run this command > > while associated to the access point: > > tcpdump -n -i iwm0 -v -y IEEE802_11_RADIO

Re: add 802.11n 40MHz support to iwn(4)

On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote: > To check whether your access point uses a 40MHz channel, run this command > while associated to the access point: > tcpdump -n -i iwm0 -v -y IEEE802_11_RADIO -s 4096 type mgt and subtype > beacon Oops, this should of course say

add 802.11n 40MHz support to iwn(4)

This patch adds 802.11n 40MHz support to the iwn(4) driver. This driver supports many different devices. Please try to be precise about which device you have tested so I can maintain a record of our test coverage. I have tested on a 6205 device. More tests are needed, especially on the old 4965AG

Re: uniq(1): support arbitrarily long lines

On 2021/10/31 20:48, Scott Cheloha wrote: > In uniq(1), if we use getline(3) instead of fgets(3) we can support > arbitrarily long lines. It works for me, and getting rid of the length restriction is nice. I don't know how much of a concern it is, but it's about twice as slow: $ wc -l /tmp/z 10