Re: sysupgrade: exit 1 instead of exit 0 when ending early
On 2022-10-07 14:39 -04, Josh Grosse wrote: > For ease of running sysupgrade from within a script. > > diff --git a/usr.sbin/sysupgrade/sysupgrade.sh > b/usr.sbin/sysupgrade/sysupgrade.sh > index d80ff127ffa..ce5800093c9 100644 > --- a/usr.sbin/sysupgrade/sysupgrade.sh > +++ b/usr.sbin/sysupgrade/sysupgrade.sh > @@ -153,7 +153,7 @@ rm SHA256.sig > > if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then > echo "Already on latest snapshot." > - exit 0 > + exit 1 > fi > > # INSTALL.*, bsd*, *.tgz > Being up2date doesn't feel like an error to me, what am I missing? -- I'm not entirely sure you are real.
Re: ThinkPad X13s and OpenBSD
On Fri, Oct 07, 2022 at 01:44:50PM -0700, Mike Larkin wrote: > On Fri, Oct 07, 2022 at 11:59:49AM -0700, Bryan Vyhmeister wrote: > > Hey Patrick, > > > > I hope you're doing well. We have not talked in quite a while. I was > > wondering how well the support for the ThinkPad X13s works right now in > > OpenBSD. I did some searching around and couldn't find much other than > > "support being added" but I'm not sure if that means everything works or > > there is just basic booting without most of the hardware working at all. > > > > I am hoping that support for the X55 5G modem might come eventually. I > > bought a ThinkPad X1 Nano with the X55 hoping it might be an easy > > addition to umb(4) but Gerhard said it's totally different and not > > something that can be added to umb(4). I am a little disappointed about > > that but such things happen. > > I'm not patrick@ but here you go: > > Stuff I can say for sure works: > basic stuff like video (simplefb), keyboard, trackpoint/trackpad, usb, nvme, > smp, > power on/off/reboot, FDE via softraid > > Stuff that doesnt work that you'd probably want on a daily driver laptop: > battery status, zzz, ZZZ, RTC > > Stuff that doesnt work and that will probably take a long time to make work: > GPU/accelerated video, 5g modem, wifi, camera, sound > > Wifi and sound can be handled with usb devices. Maybe camera too. :shrug: on > the rest. Thanks for your response. That's quite helpful. The "daily driver list" is pretty important. I suppose I will stick with amd64 for now until some more progress is made on arm64. Thank you! Bryan
Re: ThinkPad X13s and OpenBSD
On Fri, Oct 07, 2022 at 11:59:49AM -0700, Bryan Vyhmeister wrote: > Hey Patrick, > > I hope you're doing well. We have not talked in quite a while. I was > wondering how well the support for the ThinkPad X13s works right now in > OpenBSD. I did some searching around and couldn't find much other than > "support being added" but I'm not sure if that means everything works or > there is just basic booting without most of the hardware working at all. > > I am hoping that support for the X55 5G modem might come eventually. I > bought a ThinkPad X1 Nano with the X55 hoping it might be an easy > addition to umb(4) but Gerhard said it's totally different and not > something that can be added to umb(4). I am a little disappointed about > that but such things happen. > > Bryan > I'm not patrick@ but here you go: Stuff I can say for sure works: basic stuff like video (simplefb), keyboard, trackpoint/trackpad, usb, nvme, smp, power on/off/reboot, FDE via softraid Stuff that doesnt work that you'd probably want on a daily driver laptop: battery status, zzz, ZZZ, RTC Stuff that doesnt work and that will probably take a long time to make work: GPU/accelerated video, 5g modem, wifi, camera, sound Wifi and sound can be handled with usb devices. Maybe camera too. :shrug: on the rest. -ml
ThinkPad X13s and OpenBSD
Hey Patrick, I hope you're doing well. We have not talked in quite a while. I was wondering how well the support for the ThinkPad X13s works right now in OpenBSD. I did some searching around and couldn't find much other than "support being added" but I'm not sure if that means everything works or there is just basic booting without most of the hardware working at all. I am hoping that support for the X55 5G modem might come eventually. I bought a ThinkPad X1 Nano with the X55 hoping it might be an easy addition to umb(4) but Gerhard said it's totally different and not something that can be added to umb(4). I am a little disappointed about that but such things happen. Bryan
sysupgrade: exit 1 instead of exit 0 when ending early
For ease of running sysupgrade from within a script. diff --git a/usr.sbin/sysupgrade/sysupgrade.sh b/usr.sbin/sysupgrade/sysupgrade.sh index d80ff127ffa..ce5800093c9 100644 --- a/usr.sbin/sysupgrade/sysupgrade.sh +++ b/usr.sbin/sysupgrade/sysupgrade.sh @@ -153,7 +153,7 @@ rm SHA256.sig if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then echo "Already on latest snapshot." - exit 0 + exit 1 fi # INSTALL.*, bsd*, *.tgz
Re: [PATCH] ssh: don't make the umask more permissive than the user has set
On 10/6/22 16:46, Damien Miller wrote: > On Tue, 4 Oct 2022, Alex Henrie wrote: > >> Daniel Kahn Gillmor suggested this exact change on the openssh-unix-dev >> mailing list in 2008, but I couldn't find any reply. [1] >> >> Ignoring the current umask makes it hard to fulfill the Defense >> Information Systems Agency's Security Technical Implementation Guide. In >> particular, it requires: >> >> "The Red Hat Enterprise Linux operating system must be configured so >> that all files and directories contained in local interactive user home >> directories have a mode of 0750 or less permissive." [2] >> >> "The Red Hat Enterprise Linux operating system must set the umask value >> to 077 for all local interactive user accounts." [3] > Thanks - applied with a slight tweak: > > - umask(022); > + umask(022 | umask(077)); > > which better matches what we do in sshd. That looks great, thank you! -Alex
Re: tsc: AMD Family 17h, 19h: compute frequency from MSRs
> Date: Fri, 7 Oct 2022 12:38:24 -0500
> From: Scott Cheloha
>
> On Fri, Oct 07, 2022 at 11:27:45AM -0500, Scott Cheloha wrote:
> > On Fri, Oct 07, 2022 at 09:34:46AM -0500, Scott Cheloha wrote:
> > > On Thu, Sep 29, 2022 at 09:14:51AM -0500, Scott Cheloha wrote:
> > > > This patch computes the TSC frequency for AMD family 17h and 19h CPUs
> > > > (Zen microarchitecture and up) from AMD-specific MSRs. Computing the
> > > > TSC frequency is faster than calibrating with a separate timer and
> > > > introduces no error.
> > > >
> > > > We already do this for Intel CPUs in tsc_freq_cpuid().
> > > >
> > > > I got several successful test reports on family 17h and 19h CPUs in
> > > > response to this mail:
> > > >
> > > > https://marc.info/?l=openbsd-tech&m=166394236029484&w=2
> > > >
> > > > The details for computing the frequency are in the PPR for 17h and
> > > > 19h, found here (page numbers are cited in the patch):
> > > >
> > > > https://www.amd.com/system/files/TechDocs/55570-B1-PUB.zip
> > > > https://www.amd.com/system/files/TechDocs/56214-B0-PUB.zip
> > > >
> > > > The process is slightly more complicated on AMD CPU families 10h-16h.
> > > > I will deal with them in a separate commit.
> > > >
> > > > ok?
> > >
> > > 1 week bump.
> >
> > Whoops, forgot the patch, my mistake.
>
> ... and sent the wrong patch.
>
> This is patch I meant to send. Sorry for the noise.
Yes that looks better.
> Index: include/specialreg.h
> ===
> RCS file: /cvs/src/sys/arch/amd64/include/specialreg.h,v
> retrieving revision 1.94
> diff -u -p -r1.94 specialreg.h
> --- include/specialreg.h 30 Aug 2022 17:09:21 - 1.94
> +++ include/specialreg.h 7 Oct 2022 17:37:14 -
> @@ -540,6 +540,10 @@
> */
> #define MSR_HWCR0xc0010015
> #define HWCR_FFDIS 0x0040
> +#define HWCR_TSCFREQSEL 0x0100
> +
> +#define MSR_PSTATEDEF(_n) (0xc0010064 + (_n))
> +#define PSTATEDEF_EN0x8000ULL
>
> #define MSR_NB_CFG 0xc001001f
> #define NB_CFG_DISIOREQLOCK 0x0004ULL
> Index: amd64/tsc.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/tsc.c,v
> retrieving revision 1.29
> diff -u -p -r1.29 tsc.c
> --- amd64/tsc.c 22 Sep 2022 04:57:08 - 1.29
> +++ amd64/tsc.c 7 Oct 2022 17:37:14 -
> @@ -100,6 +100,67 @@ tsc_freq_cpuid(struct cpu_info *ci)
> return (0);
> }
>
> +uint64_t
> +tsc_freq_msr(struct cpu_info *ci)
> +{
> + uint64_t base, def, divisor, multiplier;
> +
> + if (strcmp(cpu_vendor, "AuthenticAMD") != 0)
> + return 0;
> +
> + /*
> + * All 10h+ CPUs have Core::X86::Msr:HWCR and the TscFreqSel
> + * bit. If TscFreqSel hasn't been set, the TSC isn't advancing
> + * at the core P0 frequency and we need to calibrate by hand.
> + */
> + if (ci->ci_family < 0x10)
> + return 0;
> + if (!ISSET(rdmsr(MSR_HWCR), HWCR_TSCFREQSEL))
> + return 0;
> +
> + /*
> + * In 10h+ CPUs, Core::X86::Msr::PStateDef defines the voltage
> + * and frequency for each core P-state. We want the P0 frequency.
> + * If the En bit isn't set, the register doesn't define a valid
> + * P-state.
> + */
> + def = rdmsr(MSR_PSTATEDEF(0));
> + if (!ISSET(def, PSTATEDEF_EN))
> + return 0;
> +
> + switch (ci->ci_family) {
> + case 0x17:
> + case 0x19:
> + /*
> + * PPR for AMD Family 17h [...]:
> + * Models 01h,08h B2, Rev 3.03, pp. 33, 139-140
> + * Model 18h B1, Rev 3.16, pp. 36, 143-144
> + * Model 60h A1, Rev 3.06, pp. 33, 155-157
> + * Model 71h B0, Rev 3.06, pp. 28, 150-151
> + *
> + * PPR for AMD Family 19h [...]:
> + * Model 21h B0, Rev 3.05, pp. 33, 166-167
> + *
> + * OSRR for AMD Family 17h processors,
> + * Models 00h-2Fh, Rev 3.03, pp. 130-131
> + */
> + base = 2; /* 200.0 MHz */
> + divisor = (def >> 8) & 0x3f;
> + if (divisor <= 0x07 || divisor >= 0x2d)
> + return 0; /* reserved */
> + if (divisor >= 0x1b && divisor % 2 == 1)
> + return 0; /* reserved */
> + multiplier = def & 0xff;
> + if (multiplier <= 0x0f)
> + return 0; /* reserved */
> + break;
> + default:
> + return 0;
> + }
> +
> + return base * multiplier / divisor;
> +}
> +
> void
> tsc_identify(struct cpu_info *ci)
> {
> @@ -118,6 +179,8 @@ tsc_identify(struct cpu_info *ci)
> tsc_is_invariant = 1;
>
Re: tsc: AMD Family 17h, 19h: compute frequency from MSRs
On Fri, Oct 07, 2022 at 11:27:45AM -0500, Scott Cheloha wrote:
> On Fri, Oct 07, 2022 at 09:34:46AM -0500, Scott Cheloha wrote:
> > On Thu, Sep 29, 2022 at 09:14:51AM -0500, Scott Cheloha wrote:
> > > This patch computes the TSC frequency for AMD family 17h and 19h CPUs
> > > (Zen microarchitecture and up) from AMD-specific MSRs. Computing the
> > > TSC frequency is faster than calibrating with a separate timer and
> > > introduces no error.
> > >
> > > We already do this for Intel CPUs in tsc_freq_cpuid().
> > >
> > > I got several successful test reports on family 17h and 19h CPUs in
> > > response to this mail:
> > >
> > > https://marc.info/?l=openbsd-tech&m=166394236029484&w=2
> > >
> > > The details for computing the frequency are in the PPR for 17h and
> > > 19h, found here (page numbers are cited in the patch):
> > >
> > > https://www.amd.com/system/files/TechDocs/55570-B1-PUB.zip
> > > https://www.amd.com/system/files/TechDocs/56214-B0-PUB.zip
> > >
> > > The process is slightly more complicated on AMD CPU families 10h-16h.
> > > I will deal with them in a separate commit.
> > >
> > > ok?
> >
> > 1 week bump.
>
> Whoops, forgot the patch, my mistake.
... and sent the wrong patch.
This is patch I meant to send. Sorry for the noise.
Index: include/specialreg.h
===
RCS file: /cvs/src/sys/arch/amd64/include/specialreg.h,v
retrieving revision 1.94
diff -u -p -r1.94 specialreg.h
--- include/specialreg.h30 Aug 2022 17:09:21 - 1.94
+++ include/specialreg.h7 Oct 2022 17:37:14 -
@@ -540,6 +540,10 @@
*/
#defineMSR_HWCR0xc0010015
#defineHWCR_FFDIS 0x0040
+#defineHWCR_TSCFREQSEL 0x0100
+
+#defineMSR_PSTATEDEF(_n) (0xc0010064 + (_n))
+#definePSTATEDEF_EN0x8000ULL
#defineMSR_NB_CFG 0xc001001f
#defineNB_CFG_DISIOREQLOCK 0x0004ULL
Index: amd64/tsc.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/tsc.c,v
retrieving revision 1.29
diff -u -p -r1.29 tsc.c
--- amd64/tsc.c 22 Sep 2022 04:57:08 - 1.29
+++ amd64/tsc.c 7 Oct 2022 17:37:14 -
@@ -100,6 +100,67 @@ tsc_freq_cpuid(struct cpu_info *ci)
return (0);
}
+uint64_t
+tsc_freq_msr(struct cpu_info *ci)
+{
+ uint64_t base, def, divisor, multiplier;
+
+ if (strcmp(cpu_vendor, "AuthenticAMD") != 0)
+ return 0;
+
+ /*
+* All 10h+ CPUs have Core::X86::Msr:HWCR and the TscFreqSel
+* bit. If TscFreqSel hasn't been set, the TSC isn't advancing
+* at the core P0 frequency and we need to calibrate by hand.
+*/
+ if (ci->ci_family < 0x10)
+ return 0;
+ if (!ISSET(rdmsr(MSR_HWCR), HWCR_TSCFREQSEL))
+ return 0;
+
+ /*
+* In 10h+ CPUs, Core::X86::Msr::PStateDef defines the voltage
+* and frequency for each core P-state. We want the P0 frequency.
+* If the En bit isn't set, the register doesn't define a valid
+* P-state.
+*/
+ def = rdmsr(MSR_PSTATEDEF(0));
+ if (!ISSET(def, PSTATEDEF_EN))
+ return 0;
+
+ switch (ci->ci_family) {
+ case 0x17:
+ case 0x19:
+ /*
+* PPR for AMD Family 17h [...]:
+* Models 01h,08h B2, Rev 3.03, pp. 33, 139-140
+* Model 18h B1, Rev 3.16, pp. 36, 143-144
+* Model 60h A1, Rev 3.06, pp. 33, 155-157
+* Model 71h B0, Rev 3.06, pp. 28, 150-151
+*
+* PPR for AMD Family 19h [...]:
+* Model 21h B0, Rev 3.05, pp. 33, 166-167
+*
+* OSRR for AMD Family 17h processors,
+* Models 00h-2Fh, Rev 3.03, pp. 130-131
+*/
+ base = 2; /* 200.0 MHz */
+ divisor = (def >> 8) & 0x3f;
+ if (divisor <= 0x07 || divisor >= 0x2d)
+ return 0; /* reserved */
+ if (divisor >= 0x1b && divisor % 2 == 1)
+ return 0; /* reserved */
+ multiplier = def & 0xff;
+ if (multiplier <= 0x0f)
+ return 0; /* reserved */
+ break;
+ default:
+ return 0;
+ }
+
+ return base * multiplier / divisor;
+}
+
void
tsc_identify(struct cpu_info *ci)
{
@@ -118,6 +179,8 @@ tsc_identify(struct cpu_info *ci)
tsc_is_invariant = 1;
tsc_frequency = tsc_freq_cpuid(ci);
+ if (tsc_frequency == 0)
+ tsc_frequency = tsc_freq_msr(ci);
if (tsc_frequency > 0)
delay_init(tsc_delay, 5000);
}
Re: tsc: AMD Family 17h, 19h: compute frequency from MSRs
On Fri, Oct 07, 2022 at 09:34:46AM -0500, Scott Cheloha wrote:
> On Thu, Sep 29, 2022 at 09:14:51AM -0500, Scott Cheloha wrote:
> > This patch computes the TSC frequency for AMD family 17h and 19h CPUs
> > (Zen microarchitecture and up) from AMD-specific MSRs. Computing the
> > TSC frequency is faster than calibrating with a separate timer and
> > introduces no error.
> >
> > We already do this for Intel CPUs in tsc_freq_cpuid().
> >
> > I got several successful test reports on family 17h and 19h CPUs in
> > response to this mail:
> >
> > https://marc.info/?l=openbsd-tech&m=166394236029484&w=2
> >
> > The details for computing the frequency are in the PPR for 17h and
> > 19h, found here (page numbers are cited in the patch):
> >
> > https://www.amd.com/system/files/TechDocs/55570-B1-PUB.zip
> > https://www.amd.com/system/files/TechDocs/56214-B0-PUB.zip
> >
> > The process is slightly more complicated on AMD CPU families 10h-16h.
> > I will deal with them in a separate commit.
> >
> > ok?
>
> 1 week bump.
Whoops, forgot the patch, my mistake.
Index: amd64/tsc.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/tsc.c,v
retrieving revision 1.29
diff -u -p -r1.29 tsc.c
--- amd64/tsc.c 22 Sep 2022 04:57:08 - 1.29
+++ amd64/tsc.c 29 Sep 2022 01:52:27 -
@@ -100,6 +100,66 @@ tsc_freq_cpuid(struct cpu_info *ci)
return (0);
}
+uint64_t
+tsc_freq_msr(struct cpu_info *ci)
+{
+ uint64_t base, def, divisor, multiplier;
+
+ if (strcmp(cpu_vendor, "AuthenticAMD") != 0)
+ return 0;
+
+ /*
+* All family 10h+ CPUs have MSR_HWCR and the TscFreqSel bit.
+* If TscFreqSel is not set the TSC does not advance at the P0
+* frequency, in which case something is wrong and we need to
+* calibrate by hand.
+*/
+ if (ci->ci_family < 0x10)
+ return 0;
+ if (!ISSET(rdmsr(MSR_HWCR), HWCR_TSCFREQSEL))
+ return 0;
+
+ /*
+* In family 10h+, core P-state voltage/frequency definitions
+* are kept in MSR_PSTATEDEF. We're interested in the MSR
+* describing P0. If the EN bit isn't set, the register doesn't
+* define a valid P-state.
+*/
+ def = rdmsr(MSR_PSTATEDEF(0));
+ if (!ISSET(def, PSTATEDEF_EN))
+ return 0;
+
+ switch (ci->ci_family) {
+ case 0x17:
+ case 0x19:
+ /*
+* PPR for AMD Family 17h [...]:
+* Models 01h,08h B2, Rev 3.03, pp. 33, 139-140
+* Model 18h B1, Rev 3.16, pp. 36, 143-144
+* Model 60h A1, Rev 3.06, pp. 33, 155-157
+* Model 71h B0, Rev 3.06, pp. 28, 150-151
+*
+* PPR for AMD Family 19h [...]:
+* Model 21h B0, Rev 3.05, pp. 33, 166-167
+*
+* OSRR for AMD Family 17h processors,
+* Models 00h-2Fh, Rev 3.03, pp. 130-131
+*/
+ base = 2; /* 200.0 MHz */
+ divisor = (def >> 8) & 0x3f;
+ if (divisor < 0x8 || divisor > 0x2c)
+ return 0; /* reserved */
+ if (divisor >= 0x1b && divisor % 2 == 1)
+ return 0; /* reserved */
+ multiplier = def & 0xff;
+ break;
+ default:
+ return 0;
+ }
+
+ return base * multiplier / divisor;
+}
+
void
tsc_identify(struct cpu_info *ci)
{
@@ -118,6 +178,8 @@ tsc_identify(struct cpu_info *ci)
tsc_is_invariant = 1;
tsc_frequency = tsc_freq_cpuid(ci);
+ if (tsc_frequency == 0)
+ tsc_frequency = tsc_freq_msr(ci);
if (tsc_frequency > 0)
delay_init(tsc_delay, 5000);
}
Index: include/specialreg.h
===
RCS file: /cvs/src/sys/arch/amd64/include/specialreg.h,v
retrieving revision 1.94
diff -u -p -r1.94 specialreg.h
--- include/specialreg.h30 Aug 2022 17:09:21 - 1.94
+++ include/specialreg.h29 Sep 2022 01:52:28 -
@@ -540,6 +540,10 @@
*/
#defineMSR_HWCR0xc0010015
#defineHWCR_FFDIS 0x0040
+#defineHWCR_TSCFREQSEL 0x0100
+
+#defineMSR_PSTATEDEF(_n) (0xc0010064 + (_n))
+#definePSTATEDEF_EN0x8000ULL
#defineMSR_NB_CFG 0xc001001f
#defineNB_CFG_DISIOREQLOCK 0x0004ULL
Re: tsc: AMD Family 17h, 19h: compute frequency from MSRs
On Thu, Sep 29, 2022 at 09:14:51AM -0500, Scott Cheloha wrote: > This patch computes the TSC frequency for AMD family 17h and 19h CPUs > (Zen microarchitecture and up) from AMD-specific MSRs. Computing the > TSC frequency is faster than calibrating with a separate timer and > introduces no error. > > We already do this for Intel CPUs in tsc_freq_cpuid(). > > I got several successful test reports on family 17h and 19h CPUs in > response to this mail: > > https://marc.info/?l=openbsd-tech&m=166394236029484&w=2 > > The details for computing the frequency are in the PPR for 17h and > 19h, found here (page numbers are cited in the patch): > > https://www.amd.com/system/files/TechDocs/55570-B1-PUB.zip > https://www.amd.com/system/files/TechDocs/56214-B0-PUB.zip > > The process is slightly more complicated on AMD CPU families 10h-16h. > I will deal with them in a separate commit. 1 week bump.
bgpctl openmetric/prometheus output
This diff adds `bgpctl show metric` which is a command that dumps some
stats out in openmetric format. This format can be ingested by e.g.
prometheus and used for monitoring.
The openmetric handling is in ometric.[ch]. It is fairly basic and not
intended for long running processes. There is a struct ometric (which is
one individual metric point). This metric point can have many different
values with each value including an optional set of labels. Since the
labels are used over and over again, I used a refcount on them.
Also since most strings used in these functions are string literals I also
don't copy them. Only the values of labels are copied since those are
for example per peer.
Using a small extra diff in bgplgd I can export the metrics into
prometheus and visualize them with grafana.
Consider this an MVP that can be extended with all the infos we want.
--
:wq Claudio
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/bgpctl/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile2 May 2020 14:33:33 - 1.17
+++ Makefile27 Sep 2022 15:50:40 -
@@ -3,7 +3,8 @@
.PATH: ${.CURDIR}/../bgpd
PROG= bgpctl
-SRCS= bgpctl.c output.c output_json.c parser.c mrtparser.c util.c json.c
+SRCS= bgpctl.c output.c output_json.c output_ometric.c parser.c \
+ mrtparser.c util.c json.c ometric.c
CFLAGS+= -Wall
CFLAGS+= -Wstrict-prototypes -Wmissing-prototypes
CFLAGS+= -Wmissing-declarations
Index: bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.283
diff -u -p -r1.283 bgpctl.c
--- bgpctl.c31 Aug 2022 15:00:53 - 1.283
+++ bgpctl.c25 Sep 2022 08:35:43 -
@@ -79,7 +79,7 @@ int
main(int argc, char *argv[])
{
struct sockaddr_un sa_un;
- int fd, n, done, ch, verbose = 0;
+ int fd, n, done, numdone, ch, verbose = 0;
struct imsg imsg;
struct network_confignet;
struct parse_result *res;
@@ -256,6 +256,12 @@ main(int argc, char *argv[])
case SHOW_RIB_MEM:
imsg_compose(ibuf, IMSG_CTL_SHOW_RIB_MEM, 0, 0, -1, NULL, 0);
break;
+ case SHOW_METRIC:
+ output = &ometric_output;
+ numdone = 2;
+ imsg_compose(ibuf, IMSG_CTL_SHOW_NEIGHBOR, 0, 0, -1, NULL, 0);
+ imsg_compose(ibuf, IMSG_CTL_SHOW_RIB_MEM, 0, 0, -1, NULL, 0);
+ break;
case RELOAD:
imsg_compose(ibuf, IMSG_CTL_RELOAD, 0, 0, -1,
res->reason, sizeof(res->reason));
@@ -366,18 +372,14 @@ main(int argc, char *argv[])
break;
}
+ output->head(res);
+
+ again:
while (ibuf->w.queued)
- if (msgbuf_write(&ibuf->w) <= 0 && errno != EAGAIN)
+ if (msgbuf_write(&ibuf->w) <= 0)
err(1, "write error");
- output->head(res);
-
while (!done) {
- if ((n = imsg_read(ibuf)) == -1 && errno != EAGAIN)
- err(1, "imsg_read error");
- if (n == 0)
- errx(1, "pipe closed");
-
while (!done) {
if ((n = imsg_get(ibuf, &imsg)) == -1)
err(1, "imsg_get error");
@@ -387,6 +389,20 @@ main(int argc, char *argv[])
done = show(&imsg, res);
imsg_free(&imsg);
}
+
+ if (done)
+ break;
+
+ if ((n = imsg_read(ibuf)) == -1)
+ err(1, "imsg_read error");
+ if (n == 0)
+ errx(1, "pipe closed");
+
+ }
+
+ if (res->action == SHOW_METRIC && --numdone > 0) {
+ done = 0;
+ goto again;
}
output->tail();
@@ -416,21 +432,29 @@ show(struct imsg *imsg, struct parse_res
switch (imsg->hdr.type) {
case IMSG_CTL_SHOW_NEIGHBOR:
+ if (output->neighbor == NULL)
+ break;
p = imsg->data;
output->neighbor(p, res);
break;
case IMSG_CTL_SHOW_TIMER:
if (imsg->hdr.len < IMSG_HEADER_SIZE + sizeof(t))
errx(1, "wrong imsg len");
+ if (output->timer == NULL)
+ break;
memcpy(&t, imsg->data, sizeof(t));
if (t.type > 0 && t.type < Timer_Max)
output->timer(&t);
break;
case IMSG_CTL_SHOW_INTERFACE:
+ if (output->interface == NULL)
+ break;
iface = imsg->data;
output->interface(iface);
break;
case IMSG_CTL_SHOW_NEXTHOP:
+
