pfctl(8): reduce -k

morning. the latest changes to pfctl(8) made me see that -k is getting a little out of hand. diff below reduces the size of the text to try and keep it down a bit. it goes from about 2.5 screensful to 1.5. SYNOPSIS/usage lose about a line. my idea is to stop listing every possible combination

Re: delete pf states by exact flow info and speed it up

On Sat, Apr 22, 2017 at 08:14:06AM +0900, YASUOKA Masahiko wrote: > On Fri, 21 Apr 2017 13:52:51 +0900 (JST) > YASUOKA Masahiko wrote: > > +int > > +pfctl_parse_host(char *str, struct pf_rule_addr *addr) > > +{ > (snip) > > + if ((sbs = strchr(s, '[')) != NULL || (sbe =

snprintf(3) example warns under -Wextra

The example proper usage of snprintf(3) (under Caveats) evokes a warning when compiled with -Wextra. I presume casting ret to unsigned int would be safe, but I'll defer to those who know the nuances. #include int foo(char* string) { char buffer[128]; int ret = snprintf(buffer,

Re: snprintf(3) example warns under -Wextra

-Wextra is stupid. It is trying to persuade patterns that ignore the rules of standard C. In particular for this situation: Never add extra costs. Adding casts everywhere is HIGHLY ERROR PRONE. Unneccesary casts were among the hardest parts of the jump from 32-bit to 64-bit, since a cast means

iwm(4) multi-frame interrupt support

iwm(4) currently sets the SINGLE_FRAME_MSK bit of the Rx config register. This bit tells the firmware that the driver wants one interrupt per frame, i.e. it prevents the firmware from placing more than one frame into the 4k RX buffer. Frames can contain firmware command responses and actual 802.11

iwm(4) monitor mode

This diff adds monitor mode to iwm(4) (man page changes not included). It requires the multi-frame interrupt support diff I just sent earlier. Otherwise plenty of "unhandled firmware response" shows up in dmesg. Index: if_iwm.c ===