Re: monotonic time going back by wrong skews

2021-04-04 Thread Scott Cheloha
On Mon, Mar 29, 2021 at 02:00:01PM +0900, YASUOKA Masahiko wrote:
> On Thu, 25 Mar 2021 19:41:35 +0100 (CET)
> Mark Kettenis  wrote:
> >> From: Scott Cheloha 
> >> Date: Thu, 25 Mar 2021 13:18:04 -0500
> >> > On Wed, Mar 24, 2021 at 05:40:21PM +0900, YASUOKA Masahiko wrote:
> >> Which diff did you apply?  Yasuoka provided two diffs.
> >> 
> >> In any case, ignore this diff:
> >> 
> >> > diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
> >> > index 238a5a068e1..3b951a8b5a3 100644
> >> > --- a/sys/arch/amd64/amd64/tsc.c
> >> > +++ b/sys/arch/amd64/amd64/tsc.c
> >> > @@ -212,7 +212,8 @@ cpu_recalibrate_tsc(struct timecounter *tc)
> >> > u_int
> >> > tsc_get_timecount(struct timecounter *tc)
> >> > {
> >> > -return rdtsc_lfence() + curcpu()->ci_tsc_skew;
> >> > +//return rdtsc_lfence() + curcpu()->ci_tsc_skew;
> >> > +return rdtsc_lfence();
> >> > }
> >> > 
> >> > void
> >> 
> >> 
> >> We don't want to discard the skews, that's wrong.
> 
> I'm sorry for the confusion.

No problem.

> >> The reason it "fixes" Yasuoka's problem is because the real skews
> >> on the ESXi VMs in question are probably close to zero but our
> >> synchronization algorithm is picking huge (wrong) skews due to
> >> some other variable interfering with our measurement.
> > 
> > Right.  If a VM exit happens while we're doing our measurement, you'll
> > see a significant delay.  And a guest OS can't prevent those from
> > happening.  But even on real hardware SMM mode may interfere with our
> > measurement.
> 
> For machines like the ESXi VMs, the measurement seems to have to
> exclude such delayed values as outliers.  I think taking a lot of
> samples and choice the minimum is a good enough way for the purpose.
> 
> I updated the diff.
> 
> - delete lines for debug
> - make tsc quality lower if skew is not good enough
> - reduce difference from NetBSD
> 
> comment? ok?

If more iterations fixes your problem, great.  It isn't going to make
things worse for machines with sync'd TSCs, makes the TSC usable on
another class of machine, and is relatively cheap.

This is ok cheloha@.

You need another ok, though.

> Index: sys/arch/amd64//amd64/tsc.c
> ===
> RCS file: /disk/cvs/openbsd/src/sys/arch/amd64/amd64/tsc.c,v
> retrieving revision 1.23
> diff -u -p -r1.23 tsc.c
> --- sys/arch/amd64//amd64/tsc.c   23 Feb 2021 04:44:30 -  1.23
> +++ sys/arch/amd64//amd64/tsc.c   29 Mar 2021 04:18:31 -
> @@ -38,6 +38,7 @@ int tsc_is_invariant;
>  
>  #define  TSC_DRIFT_MAX   250
>  #define TSC_SKEW_MAX 100
> +#define  TSC_SYNC_ROUNDS 1000
>  int64_t  tsc_drift_observed;
>  
>  volatile int64_t tsc_sync_val;
> @@ -235,6 +236,7 @@ tsc_timecounter_init(struct cpu_info *ci
>   printf("%s: disabling user TSC (skew=%lld)\n",
>   ci->ci_dev->dv_xname, (long long)ci->ci_tsc_skew);
>   tsc_timecounter.tc_user = 0;
> + tsc_timecounter.tc_quality = -1000;
>   }
>  
>   if (!(ci->ci_flags & CPUF_PRIMARY) ||
> @@ -314,13 +316,19 @@ tsc_read_bp(struct cpu_info *ci, uint64_
>  void
>  tsc_sync_bp(struct cpu_info *ci)
>  {
> + int i, val, diff;
>   uint64_t bptsc, aptsc;
>  
> - tsc_read_bp(ci, &bptsc, &aptsc); /* discarded - cache effects */
> - tsc_read_bp(ci, &bptsc, &aptsc);
> + val = INT_MAX;
> + for (i = 0; i < TSC_SYNC_ROUNDS; i++) {
> + tsc_read_bp(ci, &bptsc, &aptsc);
> + diff = bptsc - aptsc;
> + if (abs(diff) < abs(val))
> + val = diff;
> + }
>  
>   /* Compute final value to adjust for skew. */
> - ci->ci_tsc_skew = bptsc - aptsc;
> + ci->ci_tsc_skew = val;
>  }
>  
>  /*
> @@ -351,8 +359,10 @@ tsc_post_ap(struct cpu_info *ci)
>  void
>  tsc_sync_ap(struct cpu_info *ci)
>  {
> - tsc_post_ap(ci);
> - tsc_post_ap(ci);
> + int i;
> +
> + for (i = 0; i < TSC_SYNC_ROUNDS; i++)
> + tsc_post_ap(ci);
>  }
>  
>  void



Re: Remove unused variables in bin/ps

2021-04-04 Thread Klemens Nanni
On Sun, Feb 14, 2021 at 03:21:45PM +0100, Daniel Kovacic wrote:
> I stumbled upon some compiler warnings in bin/.
> 
> This diff removes two unused variables in bin/ps/print.c.
> 
> I hope that such tiny contributions are welcome.
> For me, it's a test of whether I am contributing the right way.
All good, I just committed your diff, thanks.



Re: highest/lowest weight in bgpd man pages

2021-04-04 Thread Klemens Nanni
On Sat, Apr 03, 2021 at 10:53:58PM -0400, Daniel Jakots wrote:
> Hi,
> 
> I was reading bgpd.conf(5) on how to set the weight. It says:
> 
> > For prefixes with equally long paths, the prefix with the larger
> > weight is selected.
> 
> However, in bgpd(8), it says:
> 
> > 8.  The path with the lowest local weight is selected.
> 
> I went to read rde_decide.c to find which is right, prefix_cmp()
> comment says
> 
> > Returns an integer greater than or less than 0, according to
> > whether the prefix p1 is more or less preferred than the prefix p2
> 
> and the code is
> 
> if (asp1->weight > asp2->weight)
>   return 1;
> 
> 
> Comments? OK?
Looks all good, bgpd.conf.5 revision 1.87 nicely confirms previous
pitfalls around this and how the *highest* weight wins:

date: 2007/10/21 21:34:14;  author: mk;  state: Exp;  lines: +4 -2;
Being able to set the decision weight of prefixes is a nice feature, but
when it's not really documented in what way it influences the decision
process, people like myself will screw it up and assume that it gets
added to the prefix path lenth, and thus that smaller weight wins.

.. which is not the case.  Document the actual behaviour.

bgpd(8) got its list of steps around five years after that commit, so
bgpd(8) had it twisted from the start.

OK kn

> Index: bgpd.8
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.8,v
> retrieving revision 1.64
> diff -u -p -r1.64 bgpd.8
> --- bgpd.8  16 Feb 2021 08:29:16 -  1.64
> +++ bgpd.8  4 Apr 2021 02:38:17 -
> @@ -90,7 +90,7 @@ Comparison of the BGP session type.
>  Paths learned over an external (EBGP) session are preferred over those
>  learned via an internal (IBGP) session.
>  .It
> -The path with the lowest local
> +The path with the highest local
>  .Em weight
>  is selected.
>  .It
> 
> 
> 
> Cheers,
> Daniel
> 



ddb: show all mounts: honour softdep

2021-04-04 Thread Klemens Nanni
My earlier report made me question my fstab(5) contents because
filesystems mounted with "softdep" would not have the SOFTDEP flag
printed in ddb(4)'s `show all mounts' output.

Turns out ddb simply ignores the bit, but I'd argue using softdep or not
can be important information, so add it accordingly.

Here's a test snapshot VM with a single filesystem using softdep and
showing mounts in the debugger:

test# mount
/dev/sd0a on / type ffs (local, wxallowed, softdep)
test# sysctl ddb.trigger=1
Stopped at  db_enter+0x10:  popq%rbp
ddb> show all mounts
mountpoint 0x800d1000
flags 4205800
vnodecovered 0x0 syncer 0xfd801eef1d38 data 0x80087c00
vfsconf: ops 0x8202a960 name "ffs" num 1 ref 1 flags 0x201000
statvfs cache: bsize 800 iosize 4000
blocks 497095 free 84822 avail 59968
files 129598 ffiles 115439 favail 115439
f_fsidx {0x400, 0xe9b63a57} owner 0 ctime 0x606a31a6
syncwrites 58 asyncwrites = 1436
syncreads 22635 asyncreads = 0
fstype "ffs" mnton "/" mntfrom "/dev/sd0a" mntspec "5778912438e27f1e.a"
locked vnodes:
ddb> continue
ddb.trigger: 0 -> 1

Same VM/filesystem with patched kernel:

ddb> show all mounts
mountpoint 0x800c8000
flags 4205800
vnodecovered 0x0 syncer 0xfd801f247a98 data 0x80087800
vfsconf: ops 0x812ec530 name "ffs" num 1 ref 1 flags 0x201000
statvfs cache: bsize 800 iosize 4000
blocks 497095 free 84770 avail 59916
files 129598 ffiles 115439 favail 115439
f_fsidx {0x400, 0xe9b63a57} owner 0 ctime 0x606a341c
syncwrites 59 asyncwrites = 179
syncreads 13048 asyncreads = 0
fstype "ffs" mnton "/" mntfrom "/dev/sd0a" mntspec "5778912438e27f1e.a"
locked vnodes:

>From CVS history this looks like mickey simply overlooked SOFTDEP when
adding the "flags ..." output with

sys/sys/mount.h revision 1.75
sys/kern/vfs_subr.c revision 1.133
date: 2006/07/11 21:17:58;  author: mickey;  state: Exp;  lines: +126 
-1;
add mount/vnode/buf and softdep printing commands; tested on a few 
archs and will make pedro happy too (;


Use tabs not spaces while here (nicely pulling the relevant bits into
diff context).

Feedback? OK?


Index: sys/mount.h
===
RCS file: /cvs/src/sys/sys/mount.h,v
retrieving revision 1.147
diff -u -p -r1.147 mount.h
--- sys/mount.h 18 Jan 2020 08:40:19 -  1.147
+++ sys/mount.h 4 Apr 2021 21:28:33 -
@@ -387,7 +387,7 @@ struct mount {
 #defineMNT_BITS \
 "\20\001RDONLY\002SYNCHRONOUS\003NOEXEC\004NOSUID\005NODEV\006NOPERM" \
 "\007ASYNC\010EXRDONLY\011EXPORTED\012DEFEXPORTED\013EXPORTANON" \
-"\014WXALLOWED\015LOCAL\016QUOTA\017ROOTFS\020NOATIME"
+"\014WXALLOWED\015LOCAL\016QUOTA\017ROOTFS\020NOATIME\033SOFTDEP"
 
 /*
  * filesystem control flags.
@@ -399,7 +399,7 @@ struct mount {
 #defineMNT_STALLED 0x0010  /* filesystem stalled */ 
 #defineMNT_SWAPPABLE   0x0020  /* filesystem can be used for 
swap */
 #define MNT_WANTRDWR   0x0200  /* want upgrade to read/write */
-#define MNT_SOFTDEP 0x0400  /* soft dependencies being done */
+#define MNT_SOFTDEP0x0400  /* soft dependencies being done */
 #define MNT_DOOMED 0x0800  /* device behind filesystem is gone */
 
 #ifdef _KERNEL



Re: simpleaudio: set sysclk before using it

2021-04-04 Thread Mark Kettenis
> Date: Sun, 4 Apr 2021 22:24:57 +0200
> From: Klemens Nanni 
> Cc: Mark Kettenis 
> 
> On Sun, Apr 04, 2021 at 10:01:50PM +0200, Mark Kettenis wrote:
> > > Date: Sun, 4 Apr 2021 21:08:09 +0200
> > > From: Klemens Nanni 
> > > 
> > > Feedback? Objections? OK?
> > 
> > Explanation?
> > 
> > Not sure what happened here, but the reply-to was completely garbled...
> Sorry, I must've crippled the body before sending.
> 
> simpleaudio_set_params() calls set_params() which reads sysclk off the
> "i2s_clk" property before it sets that very clock's dd_set_sysclk()
> (in case there's multiplier specified).
> 
> Hence reverse the order so set_params() picks up the newly set rate.
> 
> The rate is still off on the Pinebook Pro, but I came across this when
> reading the code and it seemed wrong, so I also checked NetBSD which did
> the same with
> 
> sys/dev/fdt/ausoc.c r1.6
> "Set sysclk rate at set_format time, so the link set_format callback can read 
> the new sysclk"
> https://github.com/NetBSD/src/commit/ac8f47d1e5f46949b081c8e9d95211cdfda1e327

OK. So NetBSD's _set_format() is the equivalent of our _set_params().
So changing the order makes us match how NetBSD does things.  That
makes some sense.

ok kettenis@, but give Patrick a chance to comment as well.


> Index: dev/fdt/simpleaudio.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/simpleaudio.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 simpleaudio.c
> --- dev/fdt/simpleaudio.c 10 Jun 2020 23:55:19 -  1.1
> +++ dev/fdt/simpleaudio.c 4 Apr 2021 20:23:39 -
> @@ -300,24 +300,6 @@ simpleaudio_set_params(void *cookie, int
>   uint32_t rate;
>   int error;
>  
> - dai = sc->sc_dai_cpu;
> - hwif = dai->dd_hw_if;
> - if (hwif->set_params) {
> - error = hwif->set_params(dai->dd_cookie,
> - setmode, usemode, play, rec);
> - if (error)
> - return error;
> - }
> -
> - dai = sc->sc_dai_codec;
> - hwif = dai->dd_hw_if;
> - if (hwif->set_params) {
> - error = hwif->set_params(dai->dd_cookie,
> - setmode, usemode, play, rec);
> - if (error)
> - return error;
> - }
> -
>   if (sc->sc_mclk_fs) {
>   if (setmode & AUMODE_PLAY)
>   rate = play->sample_rate * sc->sc_mclk_fs;
> @@ -337,6 +319,24 @@ simpleaudio_set_params(void *cookie, int
>   if (error)
>   return error;
>   }
> + }
> +
> + dai = sc->sc_dai_cpu;
> + hwif = dai->dd_hw_if;
> + if (hwif->set_params) {
> + error = hwif->set_params(dai->dd_cookie,
> + setmode, usemode, play, rec);
> + if (error)
> + return error;
> + }
> +
> + dai = sc->sc_dai_codec;
> + hwif = dai->dd_hw_if;
> + if (hwif->set_params) {
> + error = hwif->set_params(dai->dd_cookie,
> + setmode, usemode, play, rec);
> + if (error)
> + return error;
>   }
>  
>   return 0;
> 



Re: mandoc: -Tlint: search /usr/local/man as well

2021-04-04 Thread Tim van der Molen
Tim van der Molen (2021-04-04 17:12 +0200):
> Tim van der Molen (2021-04-04 17:08 +0200):
> > AFAIK, -Wstyle does include style messages, but it leaves out the
> > OpenBSD-specific ones. For example:
> > 
> > $ echo '.Dd April 4, 2021\n.Os' | mandoc -Tlint
> > mandoc: :1:5: STYLE: Mdocdate missing: Dd April 4, 2021 (OpenBSD)
> > mandoc: : WARNING: missing manual title, using UNTITLED: EOF
> > mandoc: : STYLE: RCS id missing: (OpenBSD)
> > mandoc: : WARNING: no document body
> > 
> > $ echo '.Dd April 4, 2021\n.Os' | mandoc -Tlint -Wstyle
> > mandoc: : WARNING: missing manual title, using UNTITLED: EOF
> > mandoc: : WARNING: no document body

Stupid example, sorry. I meant something like this:

$ echo '.Dd 2021-04-04\n.Os' | mandoc -Tlint | grep STYLE
mandoc: :1:5: STYLE: legacy man(7) date format: Dd 2021-04-04
mandoc: :1:5: STYLE: Mdocdate missing: Dd 2021-04-04 (OpenBSD)
mandoc: : STYLE: RCS id missing: (OpenBSD)

$ echo '.Dd 2021-04-04\n.Os' | mandoc -Tlint -Wstyle | grep STYLE
mandoc: :1:5: STYLE: legacy man(7) date format: Dd 2021-04-04



Re: simpleaudio: set sysclk before using it

2021-04-04 Thread Klemens Nanni
On Sun, Apr 04, 2021 at 10:01:50PM +0200, Mark Kettenis wrote:
> > Date: Sun, 4 Apr 2021 21:08:09 +0200
> > From: Klemens Nanni 
> > 
> > Feedback? Objections? OK?
> 
> Explanation?
> 
> Not sure what happened here, but the reply-to was completely garbled...
Sorry, I must've crippled the body before sending.

simpleaudio_set_params() calls set_params() which reads sysclk off the
"i2s_clk" property before it sets that very clock's dd_set_sysclk()
(in case there's multiplier specified).

Hence reverse the order so set_params() picks up the newly set rate.

The rate is still off on the Pinebook Pro, but I came across this when
reading the code and it seemed wrong, so I also checked NetBSD which did
the same with

sys/dev/fdt/ausoc.c r1.6
"Set sysclk rate at set_format time, so the link set_format callback can read 
the new sysclk"
https://github.com/NetBSD/src/commit/ac8f47d1e5f46949b081c8e9d95211cdfda1e327


Index: dev/fdt/simpleaudio.c
===
RCS file: /cvs/src/sys/dev/fdt/simpleaudio.c,v
retrieving revision 1.1
diff -u -p -r1.1 simpleaudio.c
--- dev/fdt/simpleaudio.c   10 Jun 2020 23:55:19 -  1.1
+++ dev/fdt/simpleaudio.c   4 Apr 2021 20:23:39 -
@@ -300,24 +300,6 @@ simpleaudio_set_params(void *cookie, int
uint32_t rate;
int error;
 
-   dai = sc->sc_dai_cpu;
-   hwif = dai->dd_hw_if;
-   if (hwif->set_params) {
-   error = hwif->set_params(dai->dd_cookie,
-   setmode, usemode, play, rec);
-   if (error)
-   return error;
-   }
-
-   dai = sc->sc_dai_codec;
-   hwif = dai->dd_hw_if;
-   if (hwif->set_params) {
-   error = hwif->set_params(dai->dd_cookie,
-   setmode, usemode, play, rec);
-   if (error)
-   return error;
-   }
-
if (sc->sc_mclk_fs) {
if (setmode & AUMODE_PLAY)
rate = play->sample_rate * sc->sc_mclk_fs;
@@ -337,6 +319,24 @@ simpleaudio_set_params(void *cookie, int
if (error)
return error;
}
+   }
+
+   dai = sc->sc_dai_cpu;
+   hwif = dai->dd_hw_if;
+   if (hwif->set_params) {
+   error = hwif->set_params(dai->dd_cookie,
+   setmode, usemode, play, rec);
+   if (error)
+   return error;
+   }
+
+   dai = sc->sc_dai_codec;
+   hwif = dai->dd_hw_if;
+   if (hwif->set_params) {
+   error = hwif->set_params(dai->dd_cookie,
+   setmode, usemode, play, rec);
+   if (error)
+   return error;
}
 
return 0;



Re: simpleaudio: set sysclk before using it

2021-04-04 Thread Mark Kettenis
> Date: Sun, 4 Apr 2021 21:08:09 +0200
> From: Klemens Nanni 
> 
> Feedback? Objections? OK?

Explanation?

Not sure what happened here, but the reply-to was completely garbled...


> diff c154c5b3e913ab7299483002bea9fb9782684007 
> 274222c1624a27cde904e8964e7b663a3d0750d8
> blob - 59cda075c0a8ec80308c145ca8dfab78f36816ef
> blob + 0bbe4da7bf8ee03806130833b63cd3245b79f196
> --- sys/dev/fdt/simpleaudio.c
> +++ sys/dev/fdt/simpleaudio.c
> @@ -300,24 +300,6 @@ simpleaudio_set_params(void *cookie, int setmode, int 
>   uint32_t rate;
>   int error;
>  
> - dai = sc->sc_dai_cpu;
> - hwif = dai->dd_hw_if;
> - if (hwif->set_params) {
> - error = hwif->set_params(dai->dd_cookie,
> - setmode, usemode, play, rec);
> - if (error)
> - return error;
> - }
> -
> - dai = sc->sc_dai_codec;
> - hwif = dai->dd_hw_if;
> - if (hwif->set_params) {
> - error = hwif->set_params(dai->dd_cookie,
> - setmode, usemode, play, rec);
> - if (error)
> - return error;
> - }
> -
>   if (sc->sc_mclk_fs) {
>   if (setmode & AUMODE_PLAY)
>   rate = play->sample_rate * sc->sc_mclk_fs;
> @@ -339,6 +321,24 @@ simpleaudio_set_params(void *cookie, int setmode, int 
>   }
>   }
>  
> + dai = sc->sc_dai_cpu;
> + hwif = dai->dd_hw_if;
> + if (hwif->set_params) {
> + error = hwif->set_params(dai->dd_cookie,
> + setmode, usemode, play, rec);
> + if (error)
> + return error;
> + }
> +
> + dai = sc->sc_dai_codec;
> + hwif = dai->dd_hw_if;
> + if (hwif->set_params) {
> + error = hwif->set_params(dai->dd_cookie,
> + setmode, usemode, play, rec);
> + if (error)
> + return error;
> + }
> +
>   return 0;
>  }
>  
> 
> 
> 



ksh: fix input handling for 4 byte UTF-8 sequences

2021-04-04 Thread Sören Tempel
Hello,

Currently, ksh does not correctly calculate the length of 4 byte UTF-8
sequences in emacs input mode. For demonstration purposes try inputting
an emoji (e.g. U+1F421) at your shell prompt. These 4 byte sequences can
be identified by checking if the first four bits are set and the fifth
bit isn't. The current check for identifying these 4 byte sequences is
incorrect.

The patch below fixes this, thereby allowing users to enter emojis
(and other 4 byte UTF-8 sequences) at their shell prompt in emacs mode:

Greetings,
Sören

diff --git bin/ksh/emacs.c bin/ksh/emacs.c
index 694c402ff..970a0989d 100644
--- bin/ksh/emacs.c
+++ bin/ksh/emacs.c
@@ -1851,7 +1851,7 @@ x_e_getu8(char *buf, int off)
return -1;
buf[off++] = c;
 
-   if (c == 0xf4)
+   if ((c & 0xf8) == 0xf0)
len = 4;
else if ((c & 0xf0) == 0xe0)
len = 3;



Re: Add /dev/video0 to fbtab

2021-04-04 Thread Marcus Glocker
Thanks for your feedback Matthias.

Unfortunately there wasn't too much acceptance for this diff from the
community, so it's unlikely that it will make it in to the tree.

Cheers,
Marcus

On Sat, 3 Apr 2021 10:25:58 +0200
Matthias Schmidt  wrote:

> Hi,
> 
> * Marcus Glocker wrote:
> > On Thu, Feb 25, 2021 at 09:34:45PM +0100, Mark Kettenis wrote:
> >   
> > > 
> > > The xenodm tty should really be ttyC4 on all our architectures.  I
> > > would suggest that anywhere where you're not sure (or have
> > > something different) we shouldn't add /dev/video0.  People won't
> > > be using a webcam on those platforms anyway.  And if they do they
> > > can file a bug report and we fix things.  
> > 
> > Agree.
> > 
> > I've tested on amd64, i386 is obvious, tb@ tested on macppc.  
> 
> I am using this on amd64 for quite some while now and it is quite
> handy when joining video calls.  Any chance to get this committed?
> 
> Cheers
> 
>   Matthias
> 



simpleaudio: set sysclk before using it

2021-04-04 Thread Klemens Nanni


Feedback? Objections? OK?
 
diff c154c5b3e913ab7299483002bea9fb9782684007 
274222c1624a27cde904e8964e7b663a3d0750d8
blob - 59cda075c0a8ec80308c145ca8dfab78f36816ef
blob + 0bbe4da7bf8ee03806130833b63cd3245b79f196
--- sys/dev/fdt/simpleaudio.c
+++ sys/dev/fdt/simpleaudio.c
@@ -300,24 +300,6 @@ simpleaudio_set_params(void *cookie, int setmode, int 
uint32_t rate;
int error;
 
-   dai = sc->sc_dai_cpu;
-   hwif = dai->dd_hw_if;
-   if (hwif->set_params) {
-   error = hwif->set_params(dai->dd_cookie,
-   setmode, usemode, play, rec);
-   if (error)
-   return error;
-   }
-
-   dai = sc->sc_dai_codec;
-   hwif = dai->dd_hw_if;
-   if (hwif->set_params) {
-   error = hwif->set_params(dai->dd_cookie,
-   setmode, usemode, play, rec);
-   if (error)
-   return error;
-   }
-
if (sc->sc_mclk_fs) {
if (setmode & AUMODE_PLAY)
rate = play->sample_rate * sc->sc_mclk_fs;
@@ -339,6 +321,24 @@ simpleaudio_set_params(void *cookie, int setmode, int 
}
}
 
+   dai = sc->sc_dai_cpu;
+   hwif = dai->dd_hw_if;
+   if (hwif->set_params) {
+   error = hwif->set_params(dai->dd_cookie,
+   setmode, usemode, play, rec);
+   if (error)
+   return error;
+   }
+
+   dai = sc->sc_dai_codec;
+   hwif = dai->dd_hw_if;
+   if (hwif->set_params) {
+   error = hwif->set_params(dai->dd_cookie,
+   setmode, usemode, play, rec);
+   if (error)
+   return error;
+   }
+
return 0;
 }
 




Re: uvideo(4) new quirk flag UVIDEO_FLAG_NOATTACH

2021-04-04 Thread Marcus Glocker
This diff shouldn't impact any other uvideo(4) devices so I would
welcome somebody brave to OK this :-)

Thanks,
Marcus

On Fri, 26 Mar 2021 10:15:58 +0100
Martijn van Duren  wrote:

> I'm in no way qualified to OK this, but I'd like to see this get in,
> because it does help me out :-)
> 
> martijn@
> 
> On Mon, 2021-03-15 at 08:35 +0100, Marcus Glocker wrote:
> > martijn@ has recently reported that in his machine he has two cams
> > of which one is doing IR, which isn't really supported by uvideo(4).
> > This IR device attaches always first as uvideo0, so he needs to swap
> > that regularly with his working cam which by default attaches to
> > uvideo1.
> > 
> > I came up with a new quirk flag to *not* attach certain devices.
> > Tested successfully by martijn@, the IR cam attaches to ugen0 and
> > the supported cam to uvideo0.
> > 
> > This patch shouldn't affect any supported uvideo(4) devices.
> > 
> > OK?
> > 
> > 
> > Index: sys/dev/usb/uvideo.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
> > retrieving revision 1.211
> > diff -u -p -u -p -r1.211 uvideo.c
> > --- sys/dev/usb/uvideo.c27 Jan 2021 17:28:19 -
> > 1.211 +++ sys/dev/usb/uvideo.c8 Mar 2021 22:06:51 -
> > @@ -307,6 +307,7 @@ struct video_hw_if uvideo_hw_if = {
> >  #define UVIDEO_FLAG_ISIGHT_STREAM_HEADER   0x1
> >  #define UVIDEO_FLAG_REATTACH   0x2
> >  #define UVIDEO_FLAG_VENDOR_CLASS   0x4
> > +#define UVIDEO_FLAG_NOATTACH   0x8
> >  struct uvideo_devs {
> > struct usb_devno uv_dev;
> > char*ucode_name;
> > @@ -382,6 +383,12 @@ struct uvideo_devs {
> >     NULL,
> >     UVIDEO_FLAG_VENDOR_CLASS
> > },
> > +   {   /* Infrared camera not supported */
> > +   { USB_VENDOR_CHICONY, USB_PRODUCT_CHICONY_IRCAMERA },
> > +   NULL,
> > +   NULL,
> > +   UVIDEO_FLAG_NOATTACH
> > +   },
> >  };
> >  #define uvideo_lookup(v, p) \
> > ((struct uvideo_devs *)usb_lookup(uvideo_devs, v, p))
> > @@ -480,13 +487,12 @@ uvideo_match(struct device *parent, void
> > if (id == NULL)
> > return (UMATCH_NONE);
> >  
> > -   if (id->bInterfaceClass == UICLASS_VIDEO &&
> > -   id->bInterfaceSubClass == UISUBCLASS_VIDEOCONTROL)
> > -   return (UMATCH_VENDOR_PRODUCT_CONF_IFACE);
> > -
> > -   /* quirk devices which we want to attach */
> > +   /* quirk devices */
> > quirk = uvideo_lookup(uaa->vendor, uaa->product);
> > if (quirk != NULL) {
> > +   if (quirk->flags & UVIDEO_FLAG_NOATTACH)
> > +   return (UMATCH_NONE);
> > +
> > if (quirk->flags & UVIDEO_FLAG_REATTACH)
> > return (UMATCH_VENDOR_PRODUCT_CONF_IFACE);
> >  
> > @@ -495,6 +501,10 @@ uvideo_match(struct device *parent, void
> >     id->bInterfaceSubClass ==
> > UISUBCLASS_VIDEOCONTROL) return (UMATCH_VENDOR_PRODUCT_CONF_IFACE);
> > }
> > +
> > +   if (id->bInterfaceClass == UICLASS_VIDEO &&
> > +   id->bInterfaceSubClass == UISUBCLASS_VIDEOCONTROL)
> > +   return (UMATCH_VENDOR_PRODUCT_CONF_IFACE);
> >  
> > return (UMATCH_NONE);
> >  }
> > Index: sys/dev/usb/usbdevs
> > ===
> > RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> > retrieving revision 1.731
> > diff -u -p -u -p -r1.731 usbdevs
> > --- sys/dev/usb/usbdevs 27 Feb 2021 03:03:40 -  1.731
> > +++ sys/dev/usb/usbdevs 8 Mar 2021 22:06:53 -
> > @@ -1336,6 +1336,7 @@ product CHICONY RTL8188CUS_3  0xaff9  RTL8
> >  product CHICONY RTL8188CUS_4   0xaffa  RTL8188CUS
> >  product CHICONY RTL8188CUS_5   0xaffb  RTL8188CUS
> >  product CHICONY RTL8188CUS_6   0xaffc  RTL8188CUS
> > +product CHICONY IRCAMERA   0xb615  Integrated IR Camera
> >  
> >  /* CH Products */
> >  product CHPRODUCTS PROTHROTTLE 0x00f1  Pro Throttle
> >   
> 
> 



unwind(8): open ports before daemonizing

2021-04-04 Thread Dave Voutila
I noticed on my laptop that if I tried to start unwind(8) via rcctl(8)
while I already had some other process bound to tcp/udp port 53
(e.g. unbound(8)), rcctl(8) would falsely report the service started
"ok" while in /var/log/daemon unwind(8) would report:

  fatal in main: could not bind to 127.0.0.1 or ::1 on port 53

Since unwind(8) daemonizes before the exit(3) call, rcctl(8) doesn't
identify the failure.

The below diff splits unwind.c:open_ports() and moves the socket
bind/listen calls to before calling daemon(3). The imsg composition is
kept in the location of the original call to open_ports() in main(). The
sockets have SOCK_CLOEXEC added to them since they're now created before
the fork/execvp dance creating the frontend and resolver processes.

Feedback or OK?

-dv@


Index: sbin/unwind/unwind.c
===
RCS file: /cvs/src/sbin/unwind/unwind.c,v
retrieving revision 1.61
diff -u -p -r1.61 unwind.c
--- sbin/unwind/unwind.c27 Feb 2021 10:32:28 -  1.61
+++ sbin/unwind/unwind.c4 Apr 2021 14:57:52 -
@@ -56,6 +56,13 @@ enum uw_process {
PROC_FRONTEND,
 };

+struct uw_socks {
+   int tcp4sock;
+   int tcp6sock;
+   int udp4sock;
+   int udp6sock;
+};
+
 __dead voidusage(void);
 __dead voidmain_shutdown(void);

@@ -71,7 +78,7 @@ static intmain_imsg_send_config(struct

 intmain_reload(void);
 intmain_sendall(enum imsg_type, void *, uint16_t);
-void   open_ports(void);
+void   open_ports(struct uw_socks *);
 void   solicit_dns_proposals(void);
 void   send_blocklist_fd(void);

@@ -127,6 +134,7 @@ main(int argc, char *argv[])
int  pipe_main2frontend[2], pipe_main2resolver[2];
int  control_fd, ta_fd;
char*csock, *saved_argv0;
+   struct uw_socks  socks = { -1, -1, -1, -1 };

csock = _PATH_UNWIND_SOCKET;

@@ -203,6 +211,8 @@ main(int argc, char *argv[])
log_init(debug, LOG_DAEMON);
log_setverbose(cmd_opts & (OPT_VERBOSE | OPT_VERBOSE2 | OPT_VERBOSE3));

+   open_ports(&socks);
+
if (!debug)
daemon(1, 0);

@@ -259,7 +269,15 @@ main(int argc, char *argv[])
&iev_resolver->ibuf))
fatal("could not establish imsg links");

-   open_ports();
+   /* Send opened sockets to the frontend */
+   if (socks.udp4sock != -1)
+   main_imsg_compose_frontend_fd(IMSG_UDP4SOCK, 0, socks.udp4sock);
+   if (socks.udp6sock != -1)
+   main_imsg_compose_frontend_fd(IMSG_UDP6SOCK, 0, socks.udp6sock);
+   if (socks.tcp4sock != -1)
+   main_imsg_compose_frontend_fd(IMSG_TCP4SOCK, 0, socks.tcp4sock);
+   if (socks.tcp6sock != -1)
+   main_imsg_compose_frontend_fd(IMSG_TCP6SOCK, 0, socks.tcp6sock);

if ((control_fd = control_init(csock)) == -1)
fatalx("control socket setup failed");
@@ -724,7 +742,7 @@ config_clear(struct uw_conf *conf)
 }

 void
-open_ports(void)
+open_ports(struct uw_socks *socks)
 {
struct addrinfo  hints, *res0;
int  udp4sock = -1, udp6sock = -1, error, bsize = 65535;
@@ -738,8 +756,9 @@ open_ports(void)

error = getaddrinfo("127.0.0.1", "domain", &hints, &res0);
if (!error && res0) {
-   if ((udp4sock = socket(res0->ai_family, res0->ai_socktype,
-   res0->ai_protocol)) != -1) {
+   if ((udp4sock = socket(res0->ai_family,
+   res0->ai_socktype | SOCK_CLOEXEC,
+   res0->ai_protocol)) != -1) {
if (setsockopt(udp4sock, SOL_SOCKET, SO_REUSEADDR,
&opt, sizeof(opt)) == -1)
log_warn("setting SO_REUSEADDR on socket");
@@ -759,8 +778,9 @@ open_ports(void)
hints.ai_family = AF_INET6;
error = getaddrinfo("::1", "domain", &hints, &res0);
if (!error && res0) {
-   if ((udp6sock = socket(res0->ai_family, res0->ai_socktype,
-   res0->ai_protocol)) != -1) {
+   if ((udp6sock = socket(res0->ai_family,
+   res0->ai_socktype | SOCK_CLOEXEC,
+   res0->ai_protocol)) != -1) {
if (setsockopt(udp6sock, SOL_SOCKET, SO_REUSEADDR,
&opt, sizeof(opt)) == -1)
log_warn("setting SO_REUSEADDR on socket");
@@ -783,8 +803,8 @@ open_ports(void)
error = getaddrinfo("127.0.0.1", "domain", &hints, &res0);
if (!error && res0) {
if ((tcp4sock = socket(res0->ai_family,
-   res0->ai_socktype | SOCK_NONBLOCK,
-   res0->ai_protocol)) != -1) {
+   res0->ai_socktype | SOCK_NONBLOCK | SOCK_CLOEXEC,
+   res0->ai_protocol)) != 

Re: mandoc: -Tlint: search /usr/local/man as well

2021-04-04 Thread Tim van der Molen
(Sorry, now with reply all.)

Tim van der Molen (2021-04-04 17:08 +0200):
> Klemens Nanni (2021-04-04 15:54 +0200):
> > On Sun, Apr 04, 2021 at 03:42:03PM +0200, Tim van der Molen wrote:
> > > Doesn't mandoc -Tlint -Wstyle do what you want?
> > I don't think so.  Oddly enough, `-Wstyle' does not do what I would
> > expect:  it omits STYLE messages instead of printing them.  From mandoc
> > 
> > -W level
> > Specify the minimum message level to be reported on the standard
> > error output and to affect the exit status.  The level can be
> > base, style, warning, error, or unsupp. [...]
> > 
> > That reads like `-Wstyle' should include STYLE.
> 
> AFAIK, -Wstyle does include style messages, but it leaves out the
> OpenBSD-specific ones. For example:
> 
> $ echo '.Dd April 4, 2021\n.Os' | mandoc -Tlint
> mandoc: :1:5: STYLE: Mdocdate missing: Dd April 4, 2021 (OpenBSD)
> mandoc: : WARNING: missing manual title, using UNTITLED: EOF
> mandoc: : STYLE: RCS id missing: (OpenBSD)
> mandoc: : WARNING: no document body
> 
> $ echo '.Dd April 4, 2021\n.Os' | mandoc -Tlint -Wstyle
> mandoc: : WARNING: missing manual title, using UNTITLED: EOF
> mandoc: : WARNING: no document body
> 
> > > -Wstyle also suppresses other warnings that aren't interesting for 
> > > manuals not
> > > part of OpenBSD:
> > But it would also suppress legitimate messages, e.g. `.Xr' macros with
> > misspelled manuals in the base MANPATH:
> 
> On the other hand, I imagine there are manuals in ports that refer to
> manuals that don't exist on OpenBSD. This would still give you the false
> positives you wanted to avoid. But of course that might be an acceptable
> tradeoff; I can't say a priori.
> 
> > $ echo .Xr true 1 | mandoc -mdoc -Tlint   
> > mandoc: : WARNING: missing date, using ""
> > mandoc: : WARNING: missing manual title, using UNTITLED: EOF
> > mandoc: : WARNING: missing Os macro, using ""
> > mandoc: :1:2: WARNING: content before first section header: Xr
> > $ echo .Xr tru 1 | mandoc -mdoc -Tlint 
> > mandoc: : WARNING: missing date, using ""
> > mandoc: : WARNING: missing manual title, using UNTITLED: EOF
> > mandoc: : WARNING: missing Os macro, using ""
> > mandoc: :1:2: WARNING: content before first section header: Xr
> > mandoc: :1:6: STYLE: referenced manual not found: Xr tru 1
> > $ echo .Xr tru 1 | mandoc -mdoc -Tlint -Wstyle
> > mandoc: : WARNING: missing date, using ""
> > mandoc: : WARNING: missing manual title, using UNTITLED: EOF
> > mandoc: : WARNING: missing Os macro, using ""
> > mandoc: :1:2: WARNING: content before first section header: Xr
> > 
> > > 
> > > $ mandoc -Tlint /usr/local/man/man1/stagit.1
> > > mandoc: /usr/local/man/man1/stagit.1:1:5: STYLE: Mdocdate missing: Dd 
> > > March 5, 2021 (OpenBSD)
> > > mandoc: /usr/local/man/man1/stagit.1: STYLE: RCS id missing: (OpenBSD)
> > > mandoc: /usr/local/man/man1/stagit.1:113:6: STYLE: referenced manual not 
> > > found: Xr stagit-index 1
> > > $ mandoc -Tlint -Wstyle /usr/local/man/man1/stagit.1
> > > $ echo $?
> > > 0
> > > 



Re: printf.9: document limited conversion specification syntax

2021-04-04 Thread Theo de Raadt
Yep, all good


Jason McIntyre  wrote:

> yep, better than mine. ok
> jmc
> 
> On 4 April 2021 14:41:13 BST, Klemens Nanni  wrote:
> >On Sun, Apr 04, 2021 at 07:17:27AM +0100, Jason McIntyre wrote:
> >> On Sun, Apr 04, 2021 at 01:22:23AM +0200, Klemens Nanni wrote:
> >> > @@ -119,6 +119,17 @@ send formatted strings to the ddb console, and
> >are onl
> >> >  Since each of these kernel functions is a variant of its user
> >space
> >> >  counterpart, this page describes only the differences between the
> >user
> >> >  space and kernel versions.
> >> > +.Pp
> >> > +The limited syntax of a conversion specification is:
> >> 
> >> hi. i'm fine with your diff, though cannot really judge the actual
> >> content. but the "limited syntax" text is a bit ambiguous. you could
> >> still expect from it that a full syntax version is supported.
> >Right, I do imply that nothing more is supported;  this sentence is a
> >cheap copy of printf(3)'s sentence
> >
> > The overall syntax of a conversion specification is:
> >
> >> maybe spell it out?
> >> 
> >>printf(9) supports a subset of the conversion specification
> >>available to printf(3):
> >> 
> >> sth like that?
> >Thanks, how about this?
> >
> >Only a subset of the user space conversion specification is available
> >to
> > the kernel version:
> >
> >   %[width][size]conversion
> >
> > Refer to printf(3) for functional details.
> >
> >
> >
> >Index: share/man/man9/printf.9
> >===
> >RCS file: /cvs/src/share/man/man9/printf.9,v
> >retrieving revision 1.24
> >diff -u -p -r1.24 printf.9
> >--- share/man/man9/printf.9  7 Nov 2015 03:48:25 -   1.24
> >+++ share/man/man9/printf.9  4 Apr 2021 13:39:02 -
> >@@ -119,6 +119,18 @@ send formatted strings to the ddb consol
> > Since each of these kernel functions is a variant of its user space
> > counterpart, this page describes only the differences between the user
> > space and kernel versions.
> >+.Pp
> >+Only a subset of the user space conversion specification is available
> >to the
> >+kernel version:
> >+.Bd -filled -offset indent
> >+.Sm off
> >+.Cm %
> >+.Op Ar width
> >+.Op Ar size
> >+.Ar conversion
> >+.Sm on
> >+.Ed
> >+.Pp
> > Refer to
> > .Xr printf 3
> > for functional details.
> 



Re: mandoc: -Tlint: search /usr/local/man as well

2021-04-04 Thread Klemens Nanni
On Sun, Apr 04, 2021 at 03:42:03PM +0200, Tim van der Molen wrote:
> Doesn't mandoc -Tlint -Wstyle do what you want?
I don't think so.  Oddly enough, `-Wstyle' does not do what I would
expect:  it omits STYLE messages instead of printing them.  From mandoc

-W level
Specify the minimum message level to be reported on the standard
error output and to affect the exit status.  The level can be
base, style, warning, error, or unsupp. [...]

That reads like `-Wstyle' should include STYLE.
> 
> -Wstyle also suppresses other warnings that aren't interesting for manuals not
> part of OpenBSD:
But it would also suppress legitimate messages, e.g. `.Xr' macros with
misspelled manuals in the base MANPATH:

$ echo .Xr true 1 | mandoc -mdoc -Tlint   
mandoc: : WARNING: missing date, using ""
mandoc: : WARNING: missing manual title, using UNTITLED: EOF
mandoc: : WARNING: missing Os macro, using ""
mandoc: :1:2: WARNING: content before first section header: Xr
$ echo .Xr tru 1 | mandoc -mdoc -Tlint 
mandoc: : WARNING: missing date, using ""
mandoc: : WARNING: missing manual title, using UNTITLED: EOF
mandoc: : WARNING: missing Os macro, using ""
mandoc: :1:2: WARNING: content before first section header: Xr
mandoc: :1:6: STYLE: referenced manual not found: Xr tru 1
$ echo .Xr tru 1 | mandoc -mdoc -Tlint -Wstyle
mandoc: : WARNING: missing date, using ""
mandoc: : WARNING: missing manual title, using UNTITLED: EOF
mandoc: : WARNING: missing Os macro, using ""
mandoc: :1:2: WARNING: content before first section header: Xr

> 
> $ mandoc -Tlint /usr/local/man/man1/stagit.1
> mandoc: /usr/local/man/man1/stagit.1:1:5: STYLE: Mdocdate missing: Dd March 
> 5, 2021 (OpenBSD)
> mandoc: /usr/local/man/man1/stagit.1: STYLE: RCS id missing: (OpenBSD)
> mandoc: /usr/local/man/man1/stagit.1:113:6: STYLE: referenced manual not 
> found: Xr stagit-index 1
> $ mandoc -Tlint -Wstyle /usr/local/man/man1/stagit.1
> $ echo $?
> 0
> 



Re: printf.9: document limited conversion specification syntax

2021-04-04 Thread Jason McIntyre
yep, better than mine. ok
jmc

On 4 April 2021 14:41:13 BST, Klemens Nanni  wrote:
>On Sun, Apr 04, 2021 at 07:17:27AM +0100, Jason McIntyre wrote:
>> On Sun, Apr 04, 2021 at 01:22:23AM +0200, Klemens Nanni wrote:
>> > @@ -119,6 +119,17 @@ send formatted strings to the ddb console, and
>are onl
>> >  Since each of these kernel functions is a variant of its user
>space
>> >  counterpart, this page describes only the differences between the
>user
>> >  space and kernel versions.
>> > +.Pp
>> > +The limited syntax of a conversion specification is:
>> 
>> hi. i'm fine with your diff, though cannot really judge the actual
>> content. but the "limited syntax" text is a bit ambiguous. you could
>> still expect from it that a full syntax version is supported.
>Right, I do imply that nothing more is supported;  this sentence is a
>cheap copy of printf(3)'s sentence
>
> The overall syntax of a conversion specification is:
>
>> maybe spell it out?
>> 
>>  printf(9) supports a subset of the conversion specification
>>  available to printf(3):
>> 
>> sth like that?
>Thanks, how about this?
>
>Only a subset of the user space conversion specification is available
>to
> the kernel version:
>
>   %[width][size]conversion
>
> Refer to printf(3) for functional details.
>
>
>
>Index: share/man/man9/printf.9
>===
>RCS file: /cvs/src/share/man/man9/printf.9,v
>retrieving revision 1.24
>diff -u -p -r1.24 printf.9
>--- share/man/man9/printf.97 Nov 2015 03:48:25 -   1.24
>+++ share/man/man9/printf.94 Apr 2021 13:39:02 -
>@@ -119,6 +119,18 @@ send formatted strings to the ddb consol
> Since each of these kernel functions is a variant of its user space
> counterpart, this page describes only the differences between the user
> space and kernel versions.
>+.Pp
>+Only a subset of the user space conversion specification is available
>to the
>+kernel version:
>+.Bd -filled -offset indent
>+.Sm off
>+.Cm %
>+.Op Ar width
>+.Op Ar size
>+.Ar conversion
>+.Sm on
>+.Ed
>+.Pp
> Refer to
> .Xr printf 3
> for functional details.



Re: mandoc: -Tlint: search /usr/local/man as well

2021-04-04 Thread Tim van der Molen
Klemens Nanni (2021-04-03 02:33 +0200):
> It has always bothered me that linting manuals complained about missing
> manuals from packages despite their path being part of the default
> MANPATH:
> 
> No local man(1) config:
> 
>   $ echo $MANPATH
>   ksh: MANPATH: parameter not set
>   $ cat /etc/man.conf
>   cat: /etc/man.conf: No such file or directory
> 
> man(1) finds tog(1), but mandoc(1) does not:
> 
>   $ mandoc -T lint `man -w tog` | grep 'not found'
>   mandoc: /usr/local/man/man1/tog.1:35:6: STYLE: referenced manual not 
> found: Xr git-repository 5 (2 times)
>   mandoc: /usr/local/man/man1/tog.1:188:6: STYLE: referenced manual not 
> found: Xr got 1 (6 times)
> 
> Not having those STYLE "issues" also makes `mandoc -T lint' more useful
> for automatic regression/pre-commit/etc. checks in ports using it since
> even STYLE messages result in a non-zero exit status, i.e. `make test'
> for a totally fine manual would fail.
> 
> Using `-W warning' to omit STYLE message entirely is undesired because
> it silences other useful style hints as well and parsing output to work
> around all this is hackish at best.
> 
> So let's lint manuals with the default MANPATH instead of the limited
> base one.
> 
> Feedback? Objections? OK?

Doesn't mandoc -Tlint -Wstyle do what you want?

-Wstyle also suppresses other warnings that aren't interesting for manuals not
part of OpenBSD:

$ mandoc -Tlint /usr/local/man/man1/stagit.1
mandoc: /usr/local/man/man1/stagit.1:1:5: STYLE: Mdocdate missing: Dd March 5, 
2021 (OpenBSD)
mandoc: /usr/local/man/man1/stagit.1: STYLE: RCS id missing: (OpenBSD)
mandoc: /usr/local/man/man1/stagit.1:113:6: STYLE: referenced manual not found: 
Xr stagit-index 1
$ mandoc -Tlint -Wstyle /usr/local/man/man1/stagit.1
$ echo $?
0



Re: printf.9: document limited conversion specification syntax

2021-04-04 Thread Klemens Nanni
On Sun, Apr 04, 2021 at 07:17:27AM +0100, Jason McIntyre wrote:
> On Sun, Apr 04, 2021 at 01:22:23AM +0200, Klemens Nanni wrote:
> > @@ -119,6 +119,17 @@ send formatted strings to the ddb console, and are onl
> >  Since each of these kernel functions is a variant of its user space
> >  counterpart, this page describes only the differences between the user
> >  space and kernel versions.
> > +.Pp
> > +The limited syntax of a conversion specification is:
> 
> hi. i'm fine with your diff, though cannot really judge the actual
> content. but the "limited syntax" text is a bit ambiguous. you could
> still expect from it that a full syntax version is supported.
Right, I do imply that nothing more is supported;  this sentence is a
cheap copy of printf(3)'s sentence

 The overall syntax of a conversion specification is:

> maybe spell it out?
> 
>   printf(9) supports a subset of the conversion specification
>   available to printf(3):
> 
> sth like that?
Thanks, how about this?

 Only a subset of the user space conversion specification is available to
 the kernel version:

   %[width][size]conversion

 Refer to printf(3) for functional details.



Index: share/man/man9/printf.9
===
RCS file: /cvs/src/share/man/man9/printf.9,v
retrieving revision 1.24
diff -u -p -r1.24 printf.9
--- share/man/man9/printf.9 7 Nov 2015 03:48:25 -   1.24
+++ share/man/man9/printf.9 4 Apr 2021 13:39:02 -
@@ -119,6 +119,18 @@ send formatted strings to the ddb consol
 Since each of these kernel functions is a variant of its user space
 counterpart, this page describes only the differences between the user
 space and kernel versions.
+.Pp
+Only a subset of the user space conversion specification is available to the
+kernel version:
+.Bd -filled -offset indent
+.Sm off
+.Cm %
+.Op Ar width
+.Op Ar size
+.Ar conversion
+.Sm on
+.Ed
+.Pp
 Refer to
 .Xr printf 3
 for functional details.



Re: Typos in ssh man pages

2021-04-04 Thread Jason McIntyre
On Sun, Apr 04, 2021 at 11:25:56AM +0200, Matthias Schmidt wrote:
> Hi,
> 
> in the recent commits to ssh(d)_config.5 two typos slipped in (looks like
> classic "switch vi to edit mode" typo :)).
> 
> Cheers
> 
>   Matthias
> 

fixed, thanks.
jmc

> 
> diff --git a/usr.bin/ssh/ssh_config.5 b/usr.bin/ssh/ssh_config.5
> index 5202196bce5..cf7391d9ce1 100644
> --- a/usr.bin/ssh/ssh_config.5
> +++ b/usr.bin/ssh/ssh_config.5
> @@ -373,7 +373,7 @@ by certificate authorities (CAs).
>  The default is:
>  .Bd -literal -offset indent
>  ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> -sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,i
> +sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,
>  rsa-sha2-512,rsa-sha2-256
>  .Ed
>  .Pp
> diff --git a/usr.bin/ssh/sshd_config.5 b/usr.bin/ssh/sshd_config.5
> index e2509bb865f..35e9e3fdabc 100644
> --- a/usr.bin/ssh/sshd_config.5
> +++ b/usr.bin/ssh/sshd_config.5
> @@ -379,7 +379,7 @@ by certificate authorities (CAs).
>  The default is:
>  .Bd -literal -offset indent
>  ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
> -sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,i
> +sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,
>  rsa-sha2-512,rsa-sha2-256
>  .Ed
>  .Pp
> 



Typos in ssh man pages

2021-04-04 Thread Matthias Schmidt
Hi,

in the recent commits to ssh(d)_config.5 two typos slipped in (looks like
classic "switch vi to edit mode" typo :)).

Cheers

Matthias


diff --git a/usr.bin/ssh/ssh_config.5 b/usr.bin/ssh/ssh_config.5
index 5202196bce5..cf7391d9ce1 100644
--- a/usr.bin/ssh/ssh_config.5
+++ b/usr.bin/ssh/ssh_config.5
@@ -373,7 +373,7 @@ by certificate authorities (CAs).
 The default is:
 .Bd -literal -offset indent
 ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
-sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,i
+sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,
 rsa-sha2-512,rsa-sha2-256
 .Ed
 .Pp
diff --git a/usr.bin/ssh/sshd_config.5 b/usr.bin/ssh/sshd_config.5
index e2509bb865f..35e9e3fdabc 100644
--- a/usr.bin/ssh/sshd_config.5
+++ b/usr.bin/ssh/sshd_config.5
@@ -379,7 +379,7 @@ by certificate authorities (CAs).
 The default is:
 .Bd -literal -offset indent
 ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
-sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,i
+sk-ssh-ed25...@openssh.com,sk-ecdsa-sha2-nistp...@openssh.com,
 rsa-sha2-512,rsa-sha2-256
 .Ed
 .Pp