Re: Wireless Media Modes Identified in Man Page for ifmedia(4)

2023-01-21 Thread Stuart Henderson
On 2023/01/21 14:00, Thomas Dunn wrote: > Hello, > > The man page for ifmedia(4) identifies the media modes defined for IEEE802.11 > Wireless LAN under the heading "MEDIA TYPES AND OPTIONS FOR IEEE802.11 > WIRELESS LAN". > > For better consistency, I suggest changing "TYPES" to "MODES" in this

Re: Inconsistent isdigit(3) man page

2023-01-21 Thread Joerg Sonnenberger
Am Fri, Jan 20, 2023 at 09:32:38AM -0700 schrieb Bob Beck: > Various spec docs seem all over the place on this, so I am also > paging Dr. Posix in this email... Hi Philip! :) Is isdigit() > safe from being screwed up by locale or not? I think this POSIX.1-2017 (i.e. Open Group Issue 7), locales a

Re: Move SS_CANTRCVMORE and SS_RCVATMARK bits from `so_state' to `sb_state' of receive buffer

2023-01-21 Thread Alexander Bluhm
On Sat, Jan 21, 2023 at 04:53:54PM +0300, Vitaliy Makkoveev wrote: > As it was done for SS_CANTSENDMORE bit. The SS_CANTRCVMORE and > SS_RCVATMARK definition kept as is, but now these bits belongs to the > `sb_state' of receive buffer. `sb_state' ored with `so_state' when > socket data exporting to

hardclock: don't call statclock(), stathz is always non-zero

2023-01-21 Thread Scott Cheloha
All the platforms have switched to clockintr. Let's start by isolating statclock() from hardclock(). stathz is now always non-zero: statclock() must be called separately. Update several of the the stathz users to reflect that the value is always non-zero. This is a first step toward making hard

Wireless Media Modes Identified in Man Page for ifmedia(4)

2023-01-21 Thread Thomas Dunn
Hello, The man page for ifmedia(4) identifies the media modes defined for IEEE802.11 Wireless LAN under the heading "MEDIA TYPES AND OPTIONS FOR IEEE802.11 WIRELESS LAN". For better consistency, I suggest changing "TYPES" to "MODES" in this heading. Also, back on Oct. 3, 2018, the Wi-Fi Allian

OpenBSD Errata: January 21, 2023 (vmm vmd)

2023-01-21 Thread Alexander Bluhm
Errata patches for vmm(4) and vmd(8) have been released for OpenBSD 7.1 and 7.2. Binary updates for the amd64 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata71.html https://www.openbsd.org/errata7

Re: don't remove known vmd vm's on failure

2023-01-21 Thread Dave Voutila
*bump*... Anyone able to test or review? Other than bikeshedding some function naming, this isn't a dramatic change. Dave Voutila writes: > Dave Voutila writes: > >> It turns out not only does vmd have numerous error paths for handling >> when something is amiss with a guest, most of the path

wire in efi_reset on MSFT Surface systems to rix reboots

2023-01-21 Thread Dave Voutila
I've long moaned about how my Go3 can't reboot. Woe is me. Now that kettenis@ landed some scaffolding for efi(4), I would love to get my Go3 working in the reboot department. The approach I'm thinking, in the diff below, is to hook in via comparing the FirmwareVendor "string" to make sure we're do

Move SS_CANTRCVMORE and SS_RCVATMARK bits from `so_state' to `sb_state' of receive buffer

2023-01-21 Thread Vitaliy Makkoveev
As it was done for SS_CANTSENDMORE bit. The SS_CANTRCVMORE and SS_RCVATMARK definition kept as is, but now these bits belongs to the `sb_state' of receive buffer. `sb_state' ored with `so_state' when socket data exporting to the userland. Index: sys/kern/kern_sysctl.c =

Re: mem.4: be more accurate about securelevel

2023-01-21 Thread Crystal Kolipe
On Sat, Jan 21, 2023 at 10:43:08AM +, Stuart Henderson wrote: > Test machines are less of a problem, because they're test machines. Sure, we're talking about two different scenarios. > Machines where things have been enabled to debug a problem and then > forgotten are a bigger issue. > I'm

Re: mem.4: be more accurate about securelevel

2023-01-21 Thread Stuart Henderson
On 2023/01/20 18:14, Crystal Kolipe wrote: > On Fri, Jan 20, 2023 at 01:15:29PM -0700, Theo de Raadt wrote: > > Todd C. Miller wrote: > > > I wonder if it makes sense to have a version of sysctl.conf that > > > only gets used for the next reboot and then is removed, kind of > > > like /etc/rc.firs