syspatch -c as non-root
Hello all (long time no see!)
TL;DR: Allow syspatch -c run under non-priviledged user.
Reasoning: instead of putting syspatch -c in crontab, I've implemented
a Zabbix trigger. Since the Zabbix agent runs as unpriviledged user,
I had to add _zabbix line to doas.conf, allowing it to run syspatch -c.
This way it works, but in the end I want this check either in stock
Zabbix code, or in our packages. And requirement to modify doas.conf
ruins all the fun.
There is another way: writing some SUID script as simple as:
#!/bin/sh
case $1 in
missing-syspatches) syspatch -c;;
failed-services) rcctl ls failed;;
*) echo "usage: ..." >&2; exit 1;;
esac
This way we could handle all possible future root-is-required cases
at once. But adding SUID script... is it a Good Thing(TM)?
But anyway, root-only requirement for listing available syspatches
seems a bit silly.
The patch was tested on 6.6. Well, it doesn't apply cleanly to 6.6,
since "set +e" magic you see arrived in -CURRENT, but tweaked version
runs smoothly.
BTW, why do we ever call eval in unpriv()? Without eval, set +e isn't
needed, FWIW.
--
WBR,
Vadim Zhukov
Index: syspatch.sh
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
retrieving revision 1.159
diff -u -p -r1.159 syspatch.sh
--- syspatch.sh 10 Dec 2019 17:11:06 - 1.159
+++ syspatch.sh 14 Dec 2019 06:50:20 -
@@ -179,7 +179,7 @@ ls_missing()
${_MIRROR}/syspatch${_OSrev}-${_p}.tgz"
{ unpriv ${_cmd} | tar tzf -; } 2>/dev/null | while read _f; do
[[ -f /${_f} ]] || continue && echo ${_p} && pkill -u \
- _syspatch -xf "${_cmd}" || true && break
+ $_USER -xf "${_cmd}" || true && break
done
done | sort -V
}
@@ -245,22 +245,26 @@ must be run manually to install the new
unpriv()
{
- local _file=$2 _rc=0 _user=_syspatch
+ local _file=$2 _rc=0
if [[ $1 == -f && -n ${_file} ]]; then
>${_file}
- chown "${_user}" "${_file}"
+ chown "${_USER}" "${_file}"
chmod 0711 ${_TMP}
shift 2
fi
(($# >= 1))
- # XXX ksh(1) bug; send error code to the caller instead of failing hard
- set +e
- eval su -s /bin/sh ${_user} -c "'$@'" || _rc=$?
- set -e
-
- [[ -n ${_file} ]] && chown root "${_file}"
+ if (($(id -u) == 0)); then
+ # XXX ksh(1) bug; send error code to the caller instead of
failing hard
+ set +e
+ eval su -s /bin/sh ${_USER} -c "'$@'" || _rc=$?
+ set -e
+
+ [[ -n ${_file} ]] && chown root "${_file}"
+ else
+ "$@" || _rc=$?
+ fi
return ${_rc}
}
@@ -270,7 +274,7 @@ set -A _KERNV -- $(sysctl -n kern.versio
sed 's/^OpenBSD \([1-9][0-9]*\.[0-9]\)\([^ ]*\).*/\1 \2/;q')
((${#_KERNV[*]} > 1)) && sp_err "Unsupported release: ${_KERNV[0]}${_KERNV[1]}"
-[[ $@ == @(|-[[:alpha:]]) ]] || usage; [[ $@ == @(|-(c|R|r)) ]] &&
+[[ $@ == @(|-[[:alpha:]]) ]] || usage; [[ $@ == @(|-(R|r)) ]] &&
(($(id -u) != 0)) && sp_err "need root privileges"
[[ $@ == @(|-(R|r)) ]] && pgrep -qxf '/bin/ksh .*reorder_kernel' &&
sp_err "cannot apply patches while reorder_kernel is running"
@@ -290,7 +294,13 @@ _PDIR="/var/syspatch"
_TMP=$(mktemp -d -p ${TMPDIR:-/tmp} syspatch.XX)
_KARL=false
-readonly _BSDMP _KERNV _MIRROR _OSrev _PDIR _TMP
+if (($(id -u) != 0)); then
+ _USER=$(id -nu)
+else
+ _USER=_syspatch
+fi
+
+readonly _BSDMP _KERNV _MIRROR _OSrev _PDIR _TMP _USER
trap 'trap_handler' EXIT
trap exit HUP INT TERM
vmctl: print root user in status owner field
With "owner root:wheel" (any group) the `vmctl status' output
will omit the "root" part in the OWNER column:
vm "generic" {
owner "root:vms"
...
}
$ vmctl status
ID PID VCPUS MAXMEM CURMEM TTYOWNERSTATE NAME
1 - 1512M - - :vms stopped generic
It only omits it if the user is root, presumably to say "only the group
matters".
I find this special case confusing as it looks incomplete, instead just
print whatever is configured:
$ ./obj/vmctl status
ID PID VCPUS MAXMEM CURMEM TTYOWNERSTATE NAME
1 - 1512M - - root:vms stopped generic
Feedback? OK?
Index: vmctl.c
===
RCS file: /cvs/src/usr.sbin/vmctl/vmctl.c,v
retrieving revision 1.72
diff -u -p -r1.72 vmctl.c
--- vmctl.c 12 Dec 2019 03:53:38 - 1.72
+++ vmctl.c 14 Dec 2019 00:54:23 -
@@ -768,8 +768,6 @@ print_vm_info(struct vmop_info_result *l
(void)strlcpy(user, name, sizeof(user));
/* get group name */
if (vmi->vir_gid != -1) {
- if (vmi->vir_uid == 0)
- *user = '\0';
name = group_from_gid(vmi->vir_gid, 1);
if (name == NULL)
(void)snprintf(group, sizeof(group),
vm.conf.5: allow instance requires options
`allow instance' is invalid, that is the `{...}' is mandatory.
OK?
Index: vm.conf.5
===
RCS file: /cvs/src/usr.sbin/vmd/vm.conf.5,v
retrieving revision 1.46
diff -u -p -r1.46 vm.conf.5
--- vm.conf.5 13 Dec 2019 07:03:46 - 1.46
+++ vm.conf.5 14 Dec 2019 00:23:32 -
@@ -147,7 +147,7 @@ Typically this is a hostname.
.Pp
Followed by a block of parameters that is enclosed in curly brackets:
.Bl -tag -width Ds
-.It Cm allow instance Op Brq ...
+.It Cm allow instance Brq ...
Set the permissions to create VM instances.
See
.Sx VM INSTANCES .
@@ -327,7 +327,7 @@ The allowed instance options are configu
.Ar parent
VM:
.Bl -tag -width Ds
-.It Cm allow instance Op Brq ...
+.It Cm allow instance Brq ...
Allow users to use this VM as a template for VM instances.
By default, the root user can always create instances without
restrictions and users or non-root owners cannot create instances.
[PATCH] add support for more Nuvoton chips to lm(4)
Hi all,
I recently built a new system with an ASRock B450M Pro4 motherboard. This
board has a Nuvoton NCT6779D chip to monitor temperatures, fans and
voltages. OpenBSD's lm(4) currently only supports the Nuvoton NCT6776F
chip, added by Marco Pfatschbacher in 2011:
https://marc.info/?l=openbsd-cvs=132318770131497=2
NetBSD's lm(4) gained support for several other Nuvoton chips in this
commit by SAITOH Masanobu in 2017:
http://mail-index.netbsd.org/source-changes/2017/07/11/msg086253.html
I have adapted the NetBSD code to OpenBSD and confirmed that it appears to
work correctly with my NCT6779D chip. With the attached patch, I get this
in dmesg:
wbsio0 at isa0 port 0x2e/2: NCT6779D rev 0x62
lm1 at wbsio0 port 0x290/8: NCT6779D
And here's the sensor data:
$ sysctl hw.sensors.lm1
hw.sensors.lm1.temp0=29.00 degC (MB Temperature)
hw.sensors.lm1.temp1=31.00 degC (CPU Temperature)
hw.sensors.lm1.temp2=78.00 degC (Aux Temp0)
hw.sensors.lm1.temp3=98.00 degC (Aux Temp1)
hw.sensors.lm1.temp4=22.50 degC (Aux Temp2)
hw.sensors.lm1.temp5=-23.00 degC (Aux Temp3)
hw.sensors.lm1.fan0=1095 RPM (System Fan)
hw.sensors.lm1.fan1=739 RPM (CPU Fan)
hw.sensors.lm1.fan2=400 RPM (Aux Fan0)
hw.sensors.lm1.fan3=0 RPM (Aux Fan1)
hw.sensors.lm1.fan4=387 RPM (Aux Fan2)
hw.sensors.lm1.volt0=0.74 VDC (VCore)
hw.sensors.lm1.volt1=2.16 VDC (VIN1)
hw.sensors.lm1.volt2=3.33 VDC (AVCC)
hw.sensors.lm1.volt3=3.33 VDC (+3.3V)
hw.sensors.lm1.volt4=21.56 VDC (VIN0)
hw.sensors.lm1.volt5=0.87 VDC (VIN8)
hw.sensors.lm1.volt6=0.59 VDC (VIN4)
hw.sensors.lm1.volt7=3.46 VDC (+3.3VSB)
hw.sensors.lm1.volt8=0.00 VDC (VBAT)
hw.sensors.lm1.volt9=0.00 VDC (VTT)
hw.sensors.lm1.volt10=0.45 VDC (VIN5)
hw.sensors.lm1.volt11=2.13 VDC (VIN6)
hw.sensors.lm1.volt12=3.38 VDC (VIN2)
hw.sensors.lm1.volt13=5.12 VDC (VIN3)
hw.sensors.lm1.volt14=1.81 VDC (VIN7)
The motherboard and CPU temperature values look very reasonable; the Aux
Temp values look like garbage, possibly because there aren't any other
sensors on this board? Fan values look reasonable. I am unsure about the
voltage values, but the ones that claim to be 3.3 volts look sane.
This is the first non-trivial patch I'm submitting and my C is pretty
rusty, so I would appreciate review and corrections. I don't have any
other systems with different Nuvoton chips to test, so I can't confirm
that this works for the other chips.
Could anyone please review this and help me get it into commit-ready shape?
Thanks,
Joe
--
Joe Gidi
j...@entropicblur.com
"You cannot buy skill." -- Ross SeyfriedIndex: share/man/man4/lm.4
===
RCS file: /cvs/src/share/man/man4/lm.4,v
retrieving revision 1.25
diff -u -p -u -r1.25 lm.4
--- share/man/man4/lm.4 16 Jul 2013 16:05:49 - 1.25
+++ share/man/man4/lm.4 13 Dec 2019 22:49:02 -
@@ -82,7 +82,7 @@ National Semiconductor LM79
.It
National Semiconductor LM81
.It
-Nuvoton NCT6776F
+Nuvoton NCT6775F, NCT6776F, NCT6779D, NCT6791D, NCT6792D, NCT6793D, NCT6795D
.It
Winbond W83627HF, W83627THF, W83637HF and W83697HF
.It
Index: sys/dev/ic/lm78.c
===
RCS file: /cvs/src/sys/dev/ic/lm78.c,v
retrieving revision 1.24
diff -u -p -u -r1.24 lm78.c
--- sys/dev/ic/lm78.c 14 Mar 2015 03:38:47 - 1.24
+++ sys/dev/ic/lm78.c 13 Dec 2019 22:49:03 -
@@ -67,6 +67,7 @@ void wb_refresh_temp(struct lm_softc *,
void wb_refresh_fanrpm(struct lm_softc *, int);
void wb_nct6776f_refresh_fanrpm(struct lm_softc *, int);
void wb_w83792d_refresh_fanrpm(struct lm_softc *, int);
+const char * wb_nct67xx_id2str(uint8_t);
void as_refresh_temp(struct lm_softc *, int);
@@ -80,6 +81,20 @@ struct lm_chip lm_chips[] = {
{ def_match } /* Must be last */
};
+struct {
+ uint8_t id;
+ const char *str;
+} nct_chips[] = {
+ {WBSIO_ID_NCT6775F, "NCT6775F"},
+ {WBSIO_ID_NCT6776F, "NCT6776F"},
+ {WBSIO_ID_NCT5104D, "NCT5104D or 610[246]D"},
+ {WBSIO_ID_NCT6779D, "NCT6779D"},
+ {WBSIO_ID_NCT6791D, "NCT6791D"},
+ {WBSIO_ID_NCT6792D, "NCT6792D"},
+ {WBSIO_ID_NCT6793D, "NCT6793D"},
+ {WBSIO_ID_NCT6795D, "NCT6795D"},
+};
+
struct lm_sensor lm78_sensors[] = {
/* Voltage */
{ "VCore A", SENSOR_VOLTS_DC, 0, 0x20, lm_refresh_volt, RFACT_NONE },
@@ -215,6 +230,43 @@ struct lm_sensor nct6776f_sensors[] = {
{ NULL }
};
+/* NCT6779D */
+struct lm_sensor nct6779d_sensors[] = {
+ /* Voltage */
+ { "VCore", SENSOR_VOLTS_DC, 4, 0x80, lm_refresh_volt, RFACT_NONE / 2 },
+ { "VIN1", SENSOR_VOLTS_DC, 4, 0x81, lm_refresh_volt, RFACT(56, 10) / 2 },
+ { "AVCC", SENSOR_VOLTS_DC, 4, 0x82, lm_refresh_volt, RFACT(34, 34) / 2 },
+ { "+3.3V", SENSOR_VOLTS_DC, 4, 0x83, lm_refresh_volt, RFACT(34, 34) / 2 },
+ { "VIN0", SENSOR_VOLTS_DC, 4, 0x84, lm_refresh_volt, RFACT(48600, 1) },
+ { "VIN8", SENSOR_VOLTS_DC, 4, 0x85, lm_refresh_volt, RFACT_NONE / 2 },
+ { "VIN4", SENSOR_VOLTS_DC, 4, 0x86, lm_refresh_volt, RFACT_NONE },
+ { "+3.3VSB", SENSOR_VOLTS_DC, 4, 0x87, lm_refresh_volt, RFACT(34, 34) / 2
Re: ublink(4), led(4) and ledctl(1)
On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote:
> Hi,
>
> I have a ThingM blink(1) USB RGB device that shows up as uhid(4).
> The tooling is "interesting", especially with all those libusb and
> HID libraries doing the abstraction. This introduces ublink(4), a
> dedicated kernel driver for that device. There are two LEDs on the
> device, which can be modified seperately. The firmware is impress-
> ive and provides features like playing sequences and adjusting how
> long it should take to fade from one colour to another. Obviously
> this also increases the complexity of the tools involved to toggle
> those RGB LEDs. Thus, the driver is kept simple (for now).
>
> In addition to providing a way to set RGB LEDs, we can also use it
> as a watchdog. If we don't "tickle" it in a specific timeframe it
> will play a (unless otherwise programmed) random sequence, which for
> instance can be used to see that the machine has paniced. This has
> been quite useful while debugging the USB stack, because once the
> magic sequence started you know that you're in deep trouble. All
> other features are unimplemented. Gamma correction would be nice
> to have.
>
> Since there is no abstraction layer for LEDs yet, this also intro-
> duces led(4), which attaches to ublink(4), and provides /dev/ledX.
There is the machdep.led_blink sysctl CPU_LED_BLINK implemented by
multiple architectures to blink based on load average.
See
man4.hppa/lcd.4:.Ar machdep.led_blink
man4.sparc64/auxio.4:.Ar machdep.led_blink
man4.sparc64/clkbrd.4:.Ar machdep.led_blink
man4.sparc64/fhc.4:.Ar machdep.led_blink
man4.sparc64/led.4:.Ar machdep.led_blink
man4.sparc64/ppm.4:.Ar machdep.led_blink
sys/arch/alpha/include/cpu.h: { "led_blink", CTLTYPE_INT } \
sys/arch/hppa/include/cpu.h:{ "led_blink", CTLTYPE_INT }, \
sys/arch/landisk/include/cpu.h: { "led_blink", CTLTYPE_INT }
\
sys/arch/sparc64/include/cpu.h: { "led_blink", CTLTYPE_INT }, \
Re: Is uvm_map_isavail() returning 1 instead of -1?
From: "Theo de Raadt" Subject: Re: Is uvm_map_isavail() returning 1 instead of -1? Date: Fri, 13 Dec 2019 15:54:10 -0700 > Masato Asou wrote: > >> Is this correct? >> >> Index: sys/uvm/uvm_map.c >> === >> RCS file: /cvs/src/sys/uvm/uvm_map.c,v >> retrieving revision 1.259 >> diff -u -p -r1.259 uvm_map.c >> --- sys/uvm/uvm_map.c 12 Dec 2019 11:12:36 - 1.259 >> +++ sys/uvm/uvm_map.c 13 Dec 2019 22:45:40 - >> @@ -855,7 +855,7 @@ uvm_map_isavail(struct vm_map *map, stru >> } >> } >> >> - return -1; >> + return 1; >> } >> >> /* > > I see only 0 vs non-0 tests for the return value of uvm_map_isavail(). > > Am I missing something? No problem. Thank you. -- ASOU Masato
Re: Is uvm_map_isavail() returning 1 instead of -1?
Masato Asou wrote: > Is this correct? > > Index: sys/uvm/uvm_map.c > === > RCS file: /cvs/src/sys/uvm/uvm_map.c,v > retrieving revision 1.259 > diff -u -p -r1.259 uvm_map.c > --- sys/uvm/uvm_map.c 12 Dec 2019 11:12:36 - 1.259 > +++ sys/uvm/uvm_map.c 13 Dec 2019 22:45:40 - > @@ -855,7 +855,7 @@ uvm_map_isavail(struct vm_map *map, stru > } > } > > - return -1; > + return 1; > } > > /* I see only 0 vs non-0 tests for the return value of uvm_map_isavail(). Am I missing something?
Is uvm_map_isavail() returning 1 instead of -1?
Is this correct? Index: sys/uvm/uvm_map.c === RCS file: /cvs/src/sys/uvm/uvm_map.c,v retrieving revision 1.259 diff -u -p -r1.259 uvm_map.c --- sys/uvm/uvm_map.c 12 Dec 2019 11:12:36 - 1.259 +++ sys/uvm/uvm_map.c 13 Dec 2019 22:45:40 - @@ -855,7 +855,7 @@ uvm_map_isavail(struct vm_map *map, stru } } - return -1; + return 1; } /* -- ASOU Masato
Re: ublink(4), led(4) and ledctl(1)
Patrick Wildt wrote:
> On Fri, Dec 13, 2019 at 02:43:25PM -0700, Theo de Raadt wrote:
> > +__devitem(led, led*, Generic LED devices)dnl
> > +_mcdev({-led-}, led*, {-led-}, {-major_led_c-}, 660)dnl
> >
> > Mode 660 leads me to ask -- what is the group?
>
> I don't know, I figured you could help me there. I guess the
> default can be 600 and then, like you wrote in the other mail,
> people will have to chmod/chown it after every upgrade.
Yeah. Or utilize it in a wrapper.
Tough shit :)
Re: ublink(4), led(4) and ledctl(1)
On Fri, Dec 13, 2019 at 02:43:25PM -0700, Theo de Raadt wrote:
> +__devitem(led, led*, Generic LED devices)dnl
> +_mcdev({-led-}, led*, {-led-}, {-major_led_c-}, 660)dnl
>
> Mode 660 leads me to ask -- what is the group?
I don't know, I figured you could help me there. I guess the
default can be 600 and then, like you wrote in the other mail,
people will have to chmod/chown it after every upgrade.
Re: ublink(4), led(4) and ledctl(1)
+__devitem(led, led*, Generic LED devices)dnl
+_mcdev({-led-}, led*, {-led-}, {-major_led_c-}, 660)dnl
Mode 660 leads me to ask -- what is the group?
If you say wheel, that is related to the diff I sent recently.
wheel marks who can su to root. Somehow it has accidentally
gained additional powers over time, which is a disaster because
we have people running JIT in browsers who gain those powers.
I believe we should start removing those powers one by one.
ublink(4), led(4) and ledctl(1)
Hi,
I have a ThingM blink(1) USB RGB device that shows up as uhid(4).
The tooling is "interesting", especially with all those libusb and
HID libraries doing the abstraction. This introduces ublink(4), a
dedicated kernel driver for that device. There are two LEDs on the
device, which can be modified seperately. The firmware is impress-
ive and provides features like playing sequences and adjusting how
long it should take to fade from one colour to another. Obviously
this also increases the complexity of the tools involved to toggle
those RGB LEDs. Thus, the driver is kept simple (for now).
In addition to providing a way to set RGB LEDs, we can also use it
as a watchdog. If we don't "tickle" it in a specific timeframe it
will play a (unless otherwise programmed) random sequence, which for
instance can be used to see that the machine has paniced. This has
been quite useful while debugging the USB stack, because once the
magic sequence started you know that you're in deep trouble. All
other features are unimplemented. Gamma correction would be nice
to have.
Since there is no abstraction layer for LEDs yet, this also intro-
duces led(4), which attaches to ublink(4), and provides /dev/ledX.
uhidev1 at uhub0 port 3 configuration 1 interface 0 "ThingM blink(1) mk2" rev
2.00/0.02 addr 2
uhidev1: iclass 3/0, 1 report id
ublink0 at uhidev1 reportid 1
led0 at ublink0: 2 LEDs
led(4) can be improved even further. We can attach the ThinkPad
LEDs to it to control it. There are also plenty of mouses that
have controllable RGBs. We could add "human readable descrip-
tions", for instance "upper side LED" or "docking station LED",
so that users can find out more easily which LED they have to
toggle. A fading or blinking mechanism, including hardware off-
loading, can probably be added as well.
To be able to control those devices, there's ledctl(1), a simple
program that can turn on/off /dev/ledX devices and also set RGB
colours.
I only did the MAKEDEV stuff for amd64, and also there are no
manpages yet. Also I haven't run it through make build yet,
sorry. And I don't often do userland tools, so feel free to
let me know how to improve it.
Thanks,
Patrick
diff --git a/etc/MAKEDEV.common b/etc/MAKEDEV.common
index 6c48a46a74a..1ee654feb4b 100644
--- a/etc/MAKEDEV.common
+++ b/etc/MAKEDEV.common
@@ -519,6 +519,8 @@ __devitem(ipmi, ipmi*, IPMI BMC access)dnl
_mkdev(ipmi, ipmi*, {-M ipmi$U c major_ipmi_c $U 600-})dnl
__devitem(gpio, gpio*, General Purpose Input/Output)dnl
_mcdev(gpio, gpio*, gpio, {-major_gpio_c-}, 600)dnl
+__devitem(led, led*, Generic LED devices)dnl
+_mcdev({-led-}, led*, {-led-}, {-major_led_c-}, 660)dnl
__devitem(vmm, vmm, Virtual Machine Monitor)dnl
_mkdev(vmm, vmm, {-M vmm c major_vmm_c 0 600-})dnl
__devitem(pvbus, pvbus*, paravirtual device tree root)dnl
diff --git a/etc/etc.amd64/MAKEDEV b/etc/etc.amd64/MAKEDEV
index 0bf05aa2fb7..63920f63329 100644
--- a/etc/etc.amd64/MAKEDEV
+++ b/etc/etc.amd64/MAKEDEV
@@ -78,6 +78,7 @@
# gpr*GPR400 smartcard reader
# hotplug devices hot plugging
# ipmi* IPMI BMC access
+# led*Generic LED devices
# nvram NVRAM access
# kcovKernel code coverage tracing
# pci*PCI bus devices
@@ -329,6 +330,10 @@ nvram)
M nvram c 85 0 440 kmem
;;
+led*)
+ M led$U c 55 $U 660
+ ;;
+
ipmi*)
M ipmi$U c 96 $U 600
;;
diff --git a/etc/etc.amd64/MAKEDEV.md b/etc/etc.amd64/MAKEDEV.md
index 1aa4f673524..03f696e8c5a 100644
--- a/etc/etc.amd64/MAKEDEV.md
+++ b/etc/etc.amd64/MAKEDEV.md
@@ -76,6 +76,7 @@ _DEV(gpr, 80)
_DEV(hotplug, 82)
_DEV(ipmi, 96)
dnl _DEV(joy, 26)
+_DEV(led, 55)
_DEV(nvram, 85)
_DEV(kcov, 19)
_DEV(pci, 72)
diff --git a/share/man/man8/man8.amd64/MAKEDEV.8
b/share/man/man8/man8.amd64/MAKEDEV.8
index f43b5cc341f..a1c08a9738e 100644
--- a/share/man/man8/man8.amd64/MAKEDEV.8
+++ b/share/man/man8/man8.amd64/MAKEDEV.8
@@ -1,10 +1,10 @@
-.\" $OpenBSD: MAKEDEV.8,v 1.83 2018/08/19 11:51:04 anton Exp $
+.\" $OpenBSD$
.\"
.\" THIS FILE AUTOMATICALLY GENERATED. DO NOT EDIT.
.\" generated from:
.\"
.\"OpenBSD: etc.amd64/MAKEDEV.md,v 1.70 2018/08/19 11:42:33 anton Exp
-.\"OpenBSD: MAKEDEV.common,v 1.100 2018/08/19 11:42:33 anton Exp
+.\"OpenBSD: MAKEDEV.common,v 1.103 2019/06/11 14:48:56 jcs Exp
.\"OpenBSD: MAKEDEV.man,v 1.9 2017/06/06 08:11:23 tb Exp
.\"OpenBSD: MAKEDEV.mansub,v 1.2 2004/02/20 19:13:01 miod Exp
.\"
@@ -23,7 +23,7 @@
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
-.Dd $Mdocdate: August 19 2018 $
+.Dd $Mdocdate: June 6 2017 $
.Dt MAKEDEV 8 amd64
.Os
.Sh NAME
@@ -230,6 +230,9 @@ devices hot plugging, see
.It Ar ipmi*
IPMI BMC access, see
.Xr ipmi 4 .
+.It Ar led*
+Generic LED devices, see
+.Xr led 4 .
.It Ar nvram
NVRAM access, see
.Xr nvram 4 .
diff --git a/sys/arch/amd64/amd64/conf.c
bgpd rde refactor
This diff changes the way session or peer related imsgs are handled.
Instead of passing the imsg.hdr.peerid down and doing the lookup for the
peer in each function move that code up into the imsg handler.
The plan is to add an imsg queue per peer later on to make the processing
of messages more fair than what happens currently.
While there change some fatalx to warnx since it is fine to just ignore
bad GR restart messages.
OK?
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.492
diff -u -p -r1.492 rde.c
--- rde.c 13 Dec 2019 14:10:56 - 1.492
+++ rde.c 13 Dec 2019 15:09:09 -
@@ -49,7 +49,7 @@
voidrde_sighdlr(int);
voidrde_dispatch_imsg_session(struct imsgbuf *);
voidrde_dispatch_imsg_parent(struct imsgbuf *);
-int rde_update_dispatch(struct imsg *);
+voidrde_update_dispatch(struct rde_peer *, struct imsg *);
int rde_update_update(struct rde_peer *, struct filterstate *,
struct bgpd_addr *, u_int8_t);
voidrde_update_withdraw(struct rde_peer *, struct bgpd_addr *,
@@ -98,11 +98,11 @@ void peer_shutdown(void);
int peer_localaddrs(struct rde_peer *, struct bgpd_addr *);
struct rde_peer *peer_match(struct ctl_neighbor *, u_int32_t);
struct rde_peer*peer_add(u_int32_t, struct peer_config *);
-voidpeer_up(u_int32_t, struct session_up *);
-voidpeer_down(u_int32_t);
+voidpeer_up(struct rde_peer *, struct session_up *);
+voidpeer_down(struct rde_peer *);
voidpeer_flush(struct rde_peer *, u_int8_t, time_t);
-voidpeer_stale(u_int32_t, u_int8_t);
-voidpeer_dump(u_int32_t, u_int8_t);
+voidpeer_stale(struct rde_peer *, u_int8_t);
+voidpeer_dump(struct rde_peer *, u_int8_t);
static void peer_recv_eor(struct rde_peer *, u_int8_t);
static void peer_send_eor(struct rde_peer *, u_int8_t);
@@ -380,7 +380,12 @@ rde_dispatch_imsg_session(struct imsgbuf
switch (imsg.hdr.type) {
case IMSG_UPDATE:
- rde_update_dispatch();
+ if ((peer = peer_get(imsg.hdr.peerid)) == NULL) {
+ log_warnx("rde_dispatch: unknown peer id %d",
+ imsg.hdr.peerid);
+ break;
+ }
+ rde_update_dispatch(peer, );
break;
case IMSG_SESSION_ADD:
if (imsg.hdr.len - IMSG_HEADER_SIZE != sizeof(pconf))
@@ -392,10 +397,20 @@ rde_dispatch_imsg_session(struct imsgbuf
if (imsg.hdr.len - IMSG_HEADER_SIZE != sizeof(sup))
fatalx("incorrect size of session request");
memcpy(, imsg.data, sizeof(sup));
- peer_up(imsg.hdr.peerid, );
+ if ((peer = peer_get(imsg.hdr.peerid)) == NULL) {
+ log_warnx("rde_dispatch: unknown peer id %d",
+ imsg.hdr.peerid);
+ break;
+ }
+ peer_up(peer, );
break;
case IMSG_SESSION_DOWN:
- peer_down(imsg.hdr.peerid);
+ if ((peer = peer_get(imsg.hdr.peerid)) == NULL) {
+ log_warnx("rde_dispatch: unknown peer id %d",
+ imsg.hdr.peerid);
+ break;
+ }
+ peer_down(peer);
break;
case IMSG_SESSION_STALE:
if (imsg.hdr.len - IMSG_HEADER_SIZE != sizeof(aid)) {
@@ -403,9 +418,16 @@ rde_dispatch_imsg_session(struct imsgbuf
break;
}
memcpy(, imsg.data, sizeof(aid));
- if (aid >= AID_MAX)
- fatalx("IMSG_SESSION_STALE: bad AID");
- peer_stale(imsg.hdr.peerid, aid);
+ if (aid >= AID_MAX) {
+ log_warnx("IMSG_SESSION_STALE: bad AID");
+ break;
+ }
+ if ((peer = peer_get(imsg.hdr.peerid)) == NULL) {
+ log_warnx("rde_dispatch: unknown peer id %d",
+ imsg.hdr.peerid);
+ break;
+ }
+ peer_stale(peer, aid);
break;
case IMSG_SESSION_FLUSH:
if (imsg.hdr.len - IMSG_HEADER_SIZE != sizeof(aid)) {
Re: [PATCH] add support for versions with '-' before a/b/rc
On Fri, Dec 13, 2019 at 02:19:26PM +0100, Matija Skala wrote:
> Dne petek, 13. december 2019 ob 13:34:57 CET je Marc Espie napisal(a):
> > On Fri, Dec 13, 2019 at 08:45:08AM +0100, Jasper Lievisse Adriaanse wrote:
> > > Hello Matija,
> > >
> > > Could you please provide a testcase for inclusion in
> > > src/regress/usr.bin/pkg-config too? Also, is there a particular port or
> > > pkg-config file in the wild that you ran into which exhibits this
> > > particular pattern?
> > I'm going to ask more strongly: is this something that mainstream pkg-config
> > does ?
> pkgconf does do this. Not sure about pkg-config
> >
> > Also, pedantically, the change is wrong. You should always quote non-alpha
> > characters when they stand for themselves. Yes, that includes \-
> >
> Right, here a new patch
> diff --git a/regress/usr.bin/pkg-config/pcdir/alpha2.pc b/regress/usr.bin/pkg-
> config/pcdir/alpha2.pc
> new file mode 100644
> index 0..7958d3717
> --- /dev/null
> +++ b/regress/usr.bin/pkg-config/pcdir/alpha2.pc
> @@ -0,0 +1,4 @@
> +Name: alpha suffix test
> +Description: pkg-config(1) regress file
> +Version: 0.1.0-alpha2
> +Libs: -lalpha2
> diff --git a/regress/usr.bin/pkg-config/pcdir/beta2.pc b/regress/usr.bin/pkg-
> config/pcdir/beta2.pc
> new file mode 100644
> index 0..cc1959848
> --- /dev/null
> +++ b/regress/usr.bin/pkg-config/pcdir/beta2.pc
> @@ -0,0 +1,3 @@
> +Name: beta suffix test
> +Description: pkg-config(1) regress file
> +Version: 0.1.0-beta2
> diff --git a/regress/usr.bin/pkg-config/pcdir/rc2.pc b/regress/usr.bin/pkg-
> config/pcdir/rc2.pc
> new file mode 100644
> index 0..499242745
> --- /dev/null
> +++ b/regress/usr.bin/pkg-config/pcdir/rc2.pc
> @@ -0,0 +1,3 @@
> +Name: rc suffix test
> +Description: pkg-config(1) regress file
> +Version: 0.1.0-rc2
> diff --git a/usr.bin/pkg-config/pkg-config b/usr.bin/pkg-config/pkg-config
> index c1aab9576..1102696af 100644
> --- a/usr.bin/pkg-config/pkg-config
> +++ b/usr.bin/pkg-config/pkg-config
> @@ -674,13 +674,13 @@ sub compare
> # is there a valid non-numeric suffix to deal with later?
> # accepted are (in order): a(lpha) < b(eta) < rc < ' '.
> # suffix[0] is the 'alpha' part, suffix[1] is the '1' part in 'alpha1'.
> - if ($a =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
> + if ($a =~ s/\-?(rc|beta|b|alpha|a)(\d+)$//) {
> say_debug("valid suffix $1$2 found in $a$1$2.");
> $suffix_a[0] = $1;
> $suffix_a[1] = $2;
> }
>
> - if ($b =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
> + if ($b =~ s/\-?(rc|beta|b|alpha|a)(\d+)$//) {
> say_debug("valid suffix $1$2 found in $b$1$2.");
> $suffix_b[0] = $1;
> $suffix_b[1] = $2;
>
>
>
>
Fair enough. I'm okay with it then.
Re: [PATCH] add support for versions with '-' before a/b/rc
Dne petek, 13. december 2019 ob 13:34:57 CET je Marc Espie napisal(a):
> On Fri, Dec 13, 2019 at 08:45:08AM +0100, Jasper Lievisse Adriaanse wrote:
> > Hello Matija,
> >
> > Could you please provide a testcase for inclusion in
> > src/regress/usr.bin/pkg-config too? Also, is there a particular port or
> > pkg-config file in the wild that you ran into which exhibits this
> > particular pattern?
> I'm going to ask more strongly: is this something that mainstream pkg-config
> does ?
pkgconf does do this. Not sure about pkg-config
>
> Also, pedantically, the change is wrong. You should always quote non-alpha
> characters when they stand for themselves. Yes, that includes \-
>
Right, here a new patch
diff --git a/regress/usr.bin/pkg-config/pcdir/alpha2.pc b/regress/usr.bin/pkg-
config/pcdir/alpha2.pc
new file mode 100644
index 0..7958d3717
--- /dev/null
+++ b/regress/usr.bin/pkg-config/pcdir/alpha2.pc
@@ -0,0 +1,4 @@
+Name: alpha suffix test
+Description: pkg-config(1) regress file
+Version: 0.1.0-alpha2
+Libs: -lalpha2
diff --git a/regress/usr.bin/pkg-config/pcdir/beta2.pc b/regress/usr.bin/pkg-
config/pcdir/beta2.pc
new file mode 100644
index 0..cc1959848
--- /dev/null
+++ b/regress/usr.bin/pkg-config/pcdir/beta2.pc
@@ -0,0 +1,3 @@
+Name: beta suffix test
+Description: pkg-config(1) regress file
+Version: 0.1.0-beta2
diff --git a/regress/usr.bin/pkg-config/pcdir/rc2.pc b/regress/usr.bin/pkg-
config/pcdir/rc2.pc
new file mode 100644
index 0..499242745
--- /dev/null
+++ b/regress/usr.bin/pkg-config/pcdir/rc2.pc
@@ -0,0 +1,3 @@
+Name: rc suffix test
+Description: pkg-config(1) regress file
+Version: 0.1.0-rc2
diff --git a/usr.bin/pkg-config/pkg-config b/usr.bin/pkg-config/pkg-config
index c1aab9576..1102696af 100644
--- a/usr.bin/pkg-config/pkg-config
+++ b/usr.bin/pkg-config/pkg-config
@@ -674,13 +674,13 @@ sub compare
# is there a valid non-numeric suffix to deal with later?
# accepted are (in order): a(lpha) < b(eta) < rc < ' '.
# suffix[0] is the 'alpha' part, suffix[1] is the '1' part in 'alpha1'.
- if ($a =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
+ if ($a =~ s/\-?(rc|beta|b|alpha|a)(\d+)$//) {
say_debug("valid suffix $1$2 found in $a$1$2.");
$suffix_a[0] = $1;
$suffix_a[1] = $2;
}
- if ($b =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
+ if ($b =~ s/\-?(rc|beta|b|alpha|a)(\d+)$//) {
say_debug("valid suffix $1$2 found in $b$1$2.");
$suffix_b[0] = $1;
$suffix_b[1] = $2;
Re: [PATCH] add support for versions with '-' before a/b/rc
On Fri, Dec 13, 2019 at 08:45:08AM +0100, Jasper Lievisse Adriaanse wrote:
> Hello Matija,
>
> Could you please provide a testcase for inclusion in
> src/regress/usr.bin/pkg-config too?
> Also, is there a particular port or pkg-config file in the wild that you ran
> into which exhibits this particular pattern?
I'm going to ask more strongly: is this something that mainstream pkg-config
does ?
Also, pedantically, the change is wrong. You should always quote non-alpha
characters when they stand for themselves. Yes, that includes \-
> > On 12 Dec 2019, at 18:28, Matija Skala wrote:
> >
> > From fa66eb42d0bd2fec7b364644684e6a4cc9ae9baa Mon Sep 17 00:00:00 2001
> > From: Matija Skala
> > Date: Thu, 28 Nov 2019 19:24:42 +0100
> > Subject: [PATCH] add support for versions with '-' before a/b/rc
> >
> > ---
> > usr.bin/pkg-config/pkg-config | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/usr.bin/pkg-config/pkg-config b/usr.bin/pkg-config/pkg-config
> > index 6dfbd3224eb..c050e9b058e 100644
> > --- a/usr.bin/pkg-config/pkg-config
> > +++ b/usr.bin/pkg-config/pkg-config
> > @@ -674,13 +674,13 @@ sub compare
> > # is there a valid non-numeric suffix to deal with later?
> > # accepted are (in order): a(lpha) < b(eta) < rc < ' '.
> > # suffix[0] is the 'alpha' part, suffix[1] is the '1' part in 'alpha1'.
> > - if ($a =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
> > + if ($a =~ s/-?(rc|beta|b|alpha|a)(\d+)$//) {
> > say_debug("valid suffix $1$2 found in $a$1$2.");
> > $suffix_a[0] = $1;
> > $suffix_a[1] = $2;
> > }
> >
> > - if ($b =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
> > + if ($b =~ s/-?(rc|beta|b|alpha|a)(\d+)$//) {
> > say_debug("valid suffix $1$2 found in $b$1$2.");
> > $suffix_b[0] = $1;
> > $suffix_b[1] = $2;
> >
> >
>
>
Re: [PATCH] add support for versions with '-' before a/b/rc
> Could you please provide a testcase for inclusion in > src/regress/usr.bin/pkg-config too? diff --git a/regress/usr.bin/pkg-config/pcdir/minusrc.pc b/regress/usr.bin/pkg- config/pcdir/minusrc.pc new file mode 100644 index 000..5bde7da0b44 --- /dev/null +++ b/regress/usr.bin/pkg-config/pcdir/minusrc.pc @@ -0,0 +1,3 @@ +Name: minusrc suffix test +Description: pkg-config(1) regress file +Version: 0.1.0-rc2 > Also, is there a particular port or > pkg-config file in the wild that you ran into which exhibits this > particular pattern? pkg-config file of libffi 3.3rc0 has 'Version: 3.3-rc0'
bgpctl output refactoring part 2
This is the next step in refactoring the output functions in bgpctl.
This diff changes the way individual show_XY() functions are called. Up
until now they got passed an imsg and then did stuff based on the imsg
type. Now show() will look at the imsg and based on the type call the
right function for this type.
Every show_XY() function is now only displaying one object. Because of
this some additional functions have been added. Diff looks big but it is
mostly reindents because the case statement in the individual functions
got removed.
OK?
--
:wq Claudio
Index: bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.250
diff -u -p -r1.250 bgpctl.c
--- bgpctl.c13 Dec 2019 11:11:22 - 1.250
+++ bgpctl.c13 Dec 2019 12:06:59 -
@@ -51,10 +51,9 @@ enum neighbor_views {
int main(int, char *[]);
int show(struct imsg *, struct parse_result *);
char *fmt_peer(const char *, const struct bgpd_addr *, int);
-int show_summary_msg(struct imsg *);
-int show_summary_terse_msg(struct imsg *);
-int show_neighbor_terse(struct imsg *);
-int show_neighbor_msg(struct imsg *, enum neighbor_views);
+voidshow_summary(struct peer *);
+voidshow_neighbor_full(struct peer *, struct parse_result *);
+voidshow_neighbor(struct peer *, struct parse_result *res);
voidprint_neighbor_capa_mp(struct peer *);
voidprint_neighbor_capa_restart(struct peer *);
voidprint_neighbor_msgstats(struct peer *);
@@ -62,15 +61,16 @@ void print_timer(const char *, time_t)
static char*fmt_timeframe(time_t t);
static char*fmt_timeframe_core(time_t t);
voidshow_fib_flags(u_int16_t);
-int show_fib_msg(struct imsg *);
-int show_nexthop_msg(struct imsg *);
-int show_interface_msg(struct imsg *);
+voidshow_fib(struct kroute_full *);
+voidshow_fib_table(struct ktable *);
+voidshow_nexthop(struct ctl_show_nexthop *);
+voidshow_interface(struct ctl_show_interface *);
voidprint_prefix(struct bgpd_addr *, u_int8_t, u_int8_t, u_int8_t);
const char *print_origin(u_int8_t, int);
const char *print_ovs(u_int8_t, int);
voidprint_flags(u_int8_t, int);
-int show_rib_summary_msg(struct imsg *);
-int show_rib_detail_msg(struct imsg *, int);
+voidshow_rib(struct ctl_show_rib *, u_char *, size_t,
+ struct parse_result *);
voidshow_rib_brief(struct ctl_show_rib *, u_char *, size_t);
voidshow_rib_detail(struct ctl_show_rib *, u_char *, size_t, int);
voidshow_attr(void *, u_int16_t, int);
@@ -78,7 +78,8 @@ void show_communities(u_char *, size_t
voidshow_community(u_char *, u_int16_t);
voidshow_large_community(u_char *, u_int16_t);
voidshow_ext_community(u_char *, u_int16_t);
-int show_rib_memory_msg(struct imsg *);
+voidshow_rib_mem(struct rde_memstats *);
+voidshow_rib_hash(struct rde_hashstats *);
voidsend_filterset(struct imsgbuf *, struct filter_set_head *);
const char *get_errstr(u_int8_t, u_int8_t);
voidshow_mrt_dump_neighbors(struct mrt_rib *, struct mrt_peer *,
@@ -415,10 +416,84 @@ main(int argc, char *argv[])
int
show(struct imsg *imsg, struct parse_result *res)
{
- u_int rescode;
- int done = 0;
+ struct peer *p;
+ struct ctl_timer*t;
+ struct ctl_show_interface *iface;
+ struct ctl_show_nexthop *nh;
+ struct kroute_full *kf;
+ struct ktable *kt;
+ struct ctl_show_rib rib;
+ u_char *asdata;
+ struct rde_memstats stats;
+ struct rde_hashstatshash;
+ u_int rescode, ilen;
+ size_t aslen;
switch (imsg->hdr.type) {
+ case IMSG_CTL_SHOW_NEIGHBOR:
+ p = imsg->data;
+ show_neighbor(p, res);
+ break;
+ case IMSG_CTL_SHOW_TIMER:
+ t = imsg->data;
+ if (t->type > 0 && t->type < Timer_Max)
+ print_timer(timernames[t->type], t->val);
+ break;
+ case IMSG_CTL_SHOW_INTERFACE:
+ iface = imsg->data;
+ show_interface(iface);
+ break;
+ case IMSG_CTL_SHOW_NEXTHOP:
+ nh = imsg->data;
+ show_nexthop(nh);
+ break;
+ case IMSG_CTL_KROUTE:
+ case IMSG_CTL_SHOW_NETWORK:
+ if (imsg->hdr.len < IMSG_HEADER_SIZE + sizeof(*kf))
+ errx(1, "wrong imsg len");
+ kf = imsg->data;
+ show_fib(kf);
Re: re-enable iwm(4) firmware Tx retries
On Wed, Dec 11, 2019 at 08:03:59PM +0100, Stefan Sperling wrote:
> Back in February we disabled iwm firmware Tx retries at lower rates.
> This improved MiRA's Tx rate selection because bad rates do actually
> look bad, rather than being compensated for by firmware retries.
> The result was increased Tx throughput. The original discussion is here:
> https://marc.info/?l=openbsd-tech=155067514103877=2
>
> This approach has a drawback: If a given Tx rate is bad we will lose all
> frames sent at that rate. This results in user-visiable packet loss.
> The diff below attempts to reduce such user-visible packet loss by
> allowing the firmware to retry at lower rates again, but only if MiRA
> is not currently probing for a new rate.
>
> I hope this will reduce observable packet loss while still selecting
> the best Tx rate. Lightly tested on 8265. More tests welcome.
The previous version of this diff had a bug where it could potentially
put a rate which is currently being probed into the firmware's rate table.
Fixed in this version which always uses the best rate determined by the
most recent probe.
diff refs/heads/master refs/heads/probing-fixed-rate
blob - dff9f8047f5c0300a4ddde4d9b090f58c28dd8f9 (mode 644)
blob + 516c45458a8a22650715c95a7ba75f8c495c3e86 (mode 600)
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -453,6 +453,8 @@ int iwm_run(struct iwm_softc *);
intiwm_run_stop(struct iwm_softc *);
struct ieee80211_node *iwm_node_alloc(struct ieee80211com *);
void iwm_calib_timeout(void *);
+void iwm_setrates_task(void *);
+void iwm_setrates(struct iwm_node *);
intiwm_media_change(struct ifnet *);
void iwm_newstate_task(void *);
intiwm_newstate(struct ieee80211com *, enum ieee80211_state, int);
@@ -4161,13 +4163,24 @@ iwm_rx_tx_cmd_single(struct iwm_softc *sc, struct iwm_
if (txfail)
in->in_mn.txfail += tx_resp->frame_count;
if (ic->ic_state == IEEE80211_S_RUN && !in->ht_force_cck) {
- int otxmcs = ni->ni_txmcs;
+ int best_mcs;
ieee80211_mira_choose(>in_mn, ic, >in_ni);
+ /*
+* If MiRA has chosen a new TX rate we must update
+* the firwmare's LQ rate table from process context.
+* ni_txmcs may change again before the task runs so
+* cache the chosen rate in the iwm_node structure.
+*/
+ best_mcs = ieee80211_mira_get_best_mcs(>in_mn);
+ if (best_mcs != in->chosen_txmcs) {
+ in->chosen_txmcs = best_mcs;
+ iwm_add_task(sc, systq, >setrates_task);
+ }
/* Fall back to CCK rates if MCS 0 is failing. */
if (txfail && IEEE80211_IS_CHAN_2GHZ(ni->ni_chan) &&
- otxmcs == 0 && ni->ni_txmcs == 0)
+ in->chosen_txmcs == 0 && best_mcs == 0)
iwm_enable_ht_cck_fallback(sc, in);
}
}
@@ -4693,14 +4706,35 @@ iwm_tx_fill_cmd(struct iwm_softc *sc, struct iwm_node
ridx = sc->sc_fixed_ridx;
} else if (ic->ic_fixed_rate != -1) {
ridx = sc->sc_fixed_ridx;
- } else if ((ni->ni_flags & IEEE80211_NODE_HT) && !in->ht_force_cck) {
+ } else if ((ni->ni_flags & IEEE80211_NODE_HT) && !in->ht_force_cck &&
+ ieee80211_mira_is_probing(>in_mn)) {
+ /* Keep Tx rate constant while mira is probing. */
ridx = iwm_mcs2ridx[ni->ni_txmcs];
- } else {
+ } else if ((ni->ni_flags & IEEE80211_NODE_HT) && in->ht_force_cck) {
uint8_t rval;
rval = (rs->rs_rates[ni->ni_txrate] & IEEE80211_RATE_VAL);
ridx = iwm_rval2ridx(rval);
if (ridx < min_ridx)
ridx = min_ridx;
+ } else {
+ int i;
+ /* Use firmware rateset retry table. */
+ tx->initial_rate_index = 0;
+ tx->tx_flags |= htole32(IWM_TX_CMD_FLG_STA_RATE);
+ if (ni->ni_flags & IEEE80211_NODE_HT) {
+ ridx = iwm_mcs2ridx[ni->ni_txmcs];
+ return _rates[ridx];
+ }
+ ridx = (IEEE80211_IS_CHAN_5GHZ(ni->ni_chan)) ?
+ IWM_RIDX_OFDM : IWM_RIDX_CCK;
+ for (i = 0; i < ni->ni_rates.rs_nrates; i++) {
+ if (iwm_rates[i].rate == (ni->ni_txrate &
+ IEEE80211_RATE_VAL)) {
+ ridx = i;
+ break;
+ }
+ }
+ return _rates[ridx];
}
rinfo = _rates[ridx];
@@ -6631,6 +6665,9 @@ iwm_run(struct iwm_softc *sc)
/* Start
Add sizes for free() in eso(4)
Hi tech@,
Here is a diff to add sizes for free() in eso(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/eso.c
===
RCS file: /cvs/src/sys/dev/pci/eso.c,v
retrieving revision 1.44
diff -u -p -r1.44 eso.c
--- sys/dev/pci/eso.c 11 Apr 2018 04:37:19 - 1.44
+++ sys/dev/pci/eso.c 13 Dec 2019 10:02:04 -
@@ -1519,7 +1519,7 @@ eso_allocm(void *hdl, int direction, siz
error = eso_allocmem(sc, size, 32, boundary, flags, direction, ed);
if (error) {
- free(ed, type, 0);
+ free(ed, type, sizeof(*ed));
return (NULL);
}
ed->ed_next = sc->sc_dmas;
@@ -1538,7 +1538,7 @@ eso_freem(void *hdl, void *addr, int typ
if (KVADDR(p) == addr) {
eso_freemem(p);
*pp = p->ed_next;
- free(p, type, 0);
+ free(p, type, sizeof(*p));
return;
}
}
Add sizes for free() in eap(4)
Hi tech@,
Here is a diff to add sizes for free() in eap(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/eap.c
===
RCS file: /cvs/src/sys/dev/pci/eap.c,v
retrieving revision 1.56
diff -u -p -r1.56 eap.c
--- sys/dev/pci/eap.c 14 Sep 2018 08:37:34 - 1.56
+++ sys/dev/pci/eap.c 13 Dec 2019 09:36:24 -
@@ -1471,7 +1471,7 @@ eap_malloc(void *addr, int direction, si
return (0);
error = eap_allocmem(sc, size, 16, p);
if (error) {
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return (0);
}
p->next = sc->sc_dmas;
@@ -1489,7 +1489,7 @@ eap_free(void *addr, void *ptr, int pool
if (KERNADDR(p) == ptr) {
eap_freemem(sc, p);
*pp = p->next;
- free(p, pool, 0);
+ free(p, pool, sizeof(*p));
return;
}
}
Add sizes for free() in auixp(4)
Hi tech@,
Here is a diff to add sizes for free() in auixp(4).
Similar diff to the ones previously sent for other audio drivers.
Comments? OK?
Index: sys/dev/pci/auixp.c
===
RCS file: /cvs/src/sys/dev/pci/auixp.c,v
retrieving revision 1.40
diff -u -p -r1.40 auixp.c
--- sys/dev/pci/auixp.c 3 Sep 2018 05:37:32 - 1.40
+++ sys/dev/pci/auixp.c 13 Dec 2019 09:46:27 -
@@ -382,7 +382,7 @@ auixp_malloc(void *hdl, int direction, s
/* get us a dma buffer itself */
error = auixp_allocmem(sc, size, 16, dma);
if (error) {
- free(dma, pool, 0);
+ free(dma, pool, sizeof(*dma));
printf("%s: auixp_malloc: not enough memory\n",
sc->sc_dev.dv_xname);
return NULL;
@@ -415,7 +415,7 @@ auixp_free(void *hdl, void *addr, int po
SLIST_REMOVE(>sc_dma_list, dma, auixp_dma,
dma_chain);
auixp_freemem(sc, dma);
- free(dma, pool, 0);
+ free(dma, pool, sizeof(*dma));
return;
}
}
@@ -537,7 +537,7 @@ auixp_allocate_dma_chain(struct auixp_so
if (error) {
printf("%s: can't malloc dma descriptor chain\n",
sc->sc_dev.dv_xname);
- free(dma, M_DEVBUF, 0);
+ free(dma, M_DEVBUF, sizeof(*dma));
return ENOMEM;
}
Re: pfctl: Do not optimize empty rulesets
Hello,
sorry it dropped on the floor of my INBOX...
thanks for reminding.
> Yes, the main anchor prints as "" but all that is behind compile time
> -DOPT_DEBUG so regular users won't deal with it anyway, so keep the code
> simple instead of adding logging around `rs->anchor->path'.
>
> OK?
change looks good. OK sashan@
>
>
> Index: pfctl_optimize.c
> ===
> RCS file: /cvs/src/sbin/pfctl/pfctl_optimize.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 pfctl_optimize.c
> --- pfctl_optimize.c 28 Jun 2019 13:32:45 - 1.42
> +++ pfctl_optimize.c 12 Dec 2019 20:06:15 -
> @@ -270,7 +270,10 @@ pfctl_optimize_ruleset(struct pfctl *pf,
> struct pf_rule *r;
> struct pf_rulequeue *old_rules;
>
> - DEBUG("optimizing ruleset");
> + if (TAILQ_EMPTY(rs->rules.active.ptr))
> + return (0);
> +
> + DEBUG("optimizing ruleset \"%s\"", rs->anchor->path);
> memset(_buffer, 0, sizeof(table_buffer));
> skip_init();
> TAILQ_INIT(_queue);
>
Re: first part of output splitting in bgpctl
On Fri, Dec 06, 2019 at 05:46:52PM +0100, Claudio Jeker wrote:
> The output processing in bgpctl is not very extensible. And output flags
> like ssv have to hacked into the output in a bad way.
>
> This is the first bit of a much bigger shuffling action to make the output
> handling more extensible. For now this just moves the header and body
> generation into two functions (show and show_head). The generic response
> handling and the end messages are now handled a bit different. The rest of
> the code was not yet modified to keep the diff small.
>
> OK?
Ping
--
:wq Claudio
Index: bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.247
diff -u -p -r1.247 bgpctl.c
--- bgpctl.c27 Nov 2019 01:23:30 - 1.247
+++ bgpctl.c6 Dec 2019 16:38:54 -
@@ -49,10 +49,11 @@ enum neighbor_views {
#define EOL0(flag) ((flag & F_CTL_SSV) ? ';' : '\n')
int main(int, char *[]);
-char *fmt_peer(const char *, const struct bgpd_addr *, int, int);
+int show(struct imsg *, struct parse_result *);
+char *fmt_peer(const char *, const struct bgpd_addr *, int);
voidshow_summary_head(void);
-int show_summary_msg(struct imsg *, int);
-int show_summary_terse_msg(struct imsg *, int);
+int show_summary_msg(struct imsg *);
+int show_summary_terse_msg(struct imsg *);
int show_neighbor_terse(struct imsg *);
int show_neighbor_msg(struct imsg *, enum neighbor_views);
voidprint_neighbor_capa_mp(struct peer *);
@@ -76,10 +77,9 @@ const char * print_origin(u_int8_t, int
const char *print_ovs(u_int8_t, int);
voidprint_flags(u_int8_t, int);
int show_rib_summary_msg(struct imsg *);
-int show_rib_detail_msg(struct imsg *, int, int);
+int show_rib_detail_msg(struct imsg *, int);
voidshow_rib_brief(struct ctl_show_rib *, u_char *, size_t);
-voidshow_rib_detail(struct ctl_show_rib *, u_char *, size_t, int,
- int);
+voidshow_rib_detail(struct ctl_show_rib *, u_char *, size_t, int);
voidshow_attr(void *, u_int16_t, int);
voidshow_communities(u_char *, size_t, int);
voidshow_community(u_char *, u_int16_t);
@@ -88,7 +88,6 @@ void show_ext_community(u_char *, u_in
int show_rib_memory_msg(struct imsg *);
voidsend_filterset(struct imsgbuf *, struct filter_set_head *);
const char *get_errstr(u_int8_t, u_int8_t);
-int show_result(struct imsg *);
voidshow_mrt_dump_neighbors(struct mrt_rib *, struct mrt_peer *,
void *);
voidshow_mrt_dump(struct mrt_rib *, struct mrt_peer *, void *);
@@ -99,11 +98,14 @@ const char *msg_type(u_int8_t);
voidnetwork_bulk(struct parse_result *);
const char *print_auth_method(enum auth_method);
int match_aspath(void *, u_int16_t, struct filter_as *);
+voidshow_head(struct parse_result *);
+voidshow_result(u_int);
struct imsgbuf *ibuf;
struct mrt_parser show_mrt = { show_mrt_dump, show_mrt_state, show_mrt_msg };
struct mrt_parser net_mrt = { network_mrt_dump, NULL, NULL };
int tableid;
+int nodescr;
__dead void
usage(void)
@@ -119,7 +121,7 @@ int
main(int argc, char *argv[])
{
struct sockaddr_un sun;
- int fd, n, done, ch, nodescr = 0, verbose = 0;
+ int fd, n, done, ch, verbose = 0;
struct imsg imsg;
struct network_confignet;
struct parse_result *res;
@@ -180,8 +182,8 @@ main(int argc, char *argv[])
show_mrt.arg =
if (res->flags & F_CTL_NEIGHBORS)
show_mrt.dump = show_mrt_dump_neighbors;
- else if (!(res->flags & F_CTL_DETAIL))
- show_rib_summary_head();
+ else
+ show_head(res);
mrt_parse(res->mrtfd, _mrt, 1);
exit(0);
default:
@@ -218,7 +220,6 @@ main(int argc, char *argv[])
case SHOW:
case SHOW_SUMMARY:
imsg_compose(ibuf, IMSG_CTL_SHOW_NEIGHBOR, 0, 0, -1, NULL, 0);
- show_summary_head();
break;
case SHOW_SUMMARY_TERSE:
imsg_compose(ibuf, IMSG_CTL_SHOW_TERSE, 0, 0, -1, NULL, 0);
@@ -241,20 +242,16 @@ main(int argc, char *argv[])
} else
imsg_compose(ibuf, IMSG_CTL_KROUTE_ADDR, res->rtableid,
0, -1, >addr, sizeof(res->addr));
- show_fib_head();
break;
case SHOW_FIB_TABLES:
imsg_compose(ibuf, IMSG_CTL_SHOW_FIB_TABLES, 0, 0, -1, NULL, 0);
- show_fib_tables_head();
