Re: mvpcie(4): fix panic if "reset-gpios" is not available

2022-02-13 Thread Klemens Nanni
On Sun, Feb 13, 2022 at 02:30:21PM +0100, Tobias Heider wrote: > OF_getproplen() will return -1 if "reset-gpios" is not found which > currently causes a panic: > > panic: malloc: allocation too large, type = 2, size = 4294967295 > > Below is a fix. > > ok? OK kn > > Index: mvpcie.c >

Re: unlock mmap(2) for anonymous mappings

2022-02-10 Thread Klemens Nanni
On Mon, Feb 07, 2022 at 02:12:52PM +0100, Mark Kettenis wrote: > > Date: Mon, 7 Feb 2022 12:11:42 + > > From: Klemens Nanni > > > > On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote: > > > So there is the existing UVM_MAP_REQ_WRITE(). Compa

Re: unlock mmap(2) for anonymous mappings

2022-02-07 Thread Klemens Nanni
On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote: > > Date: Mon, 7 Feb 2022 11:12:50 + > > From: Klemens Nanni > > > > On Thu, Jan 27, 2022 at 11:11:48AM +, Klemens Nanni wrote: > > > On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Na

Re: unlock mmap(2) for anonymous mappings

2022-02-07 Thread Klemens Nanni
On Thu, Jan 27, 2022 at 11:11:48AM +, Klemens Nanni wrote: > On Tue, Jan 25, 2022 at 07:54:52AM +0000, Klemens Nanni wrote: > > > Could we use a vm_map_assert_locked() or something similar that reflect > > > the exclusive or shared (read) lock comments? I don't trust com

Re: uvm_unmap_kill_entry(): unwire with map lock held

2022-02-07 Thread Klemens Nanni
On Fri, Feb 04, 2022 at 01:37:41PM -0300, Martin Pieuchot wrote: > On 04/02/22(Fri) 03:39, Klemens Nanni wrote: > > [...] > > ... with the lock grabbed in uvm_map_teardown() that is, otherwise > > the first call path can lock against itself (regress/misc/posixtestsui

Re: uvm_unmap_kill_entry(): unwire with map lock held

2022-02-03 Thread Klemens Nanni
On Thu, Feb 03, 2022 at 04:49:26PM +, Klemens Nanni wrote: > On Mon, Jan 31, 2022 at 11:11:25AM -0300, Martin Pieuchot wrote: > > On 31/01/22(Mon) 10:24, Klemens Nanni wrote: > > > Running with my uvm assert diff showed that uvm_fault_unwire_locked() > > > was ca

Re: uvm_unmap_kill_entry(): unwire with map lock held

2022-02-03 Thread Klemens Nanni
On Mon, Jan 31, 2022 at 11:11:25AM -0300, Martin Pieuchot wrote: > On 31/01/22(Mon) 10:24, Klemens Nanni wrote: > > Running with my uvm assert diff showed that uvm_fault_unwire_locked() > > was called without any locks held. > > > > This happened

uvm_unmap_kill_entry(): unwire with map lock held

2022-01-31 Thread Klemens Nanni
Running with my uvm assert diff showed that uvm_fault_unwire_locked() was called without any locks held. This happened when I rebooted my machine: uvm_fault_unwire_locked() uvm_unmap_kill_entry_withlock() uvm_unmap_kill_entry() uvm_map_teardown()

Re: unlock mmap(2) for anonymous mappings

2022-01-27 Thread Klemens Nanni
On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Nanni wrote: > > Could we use a vm_map_assert_locked() or something similar that reflect > > the exclusive or shared (read) lock comments? I don't trust comments. > > It's too easy to miss a lock in a code path. > > Thi

Re: unlock mmap(2) for anonymous mappings

2022-01-24 Thread Klemens Nanni
On Mon, Jan 24, 2022 at 12:08:33PM -0300, Martin Pieuchot wrote: > On 24/01/22(Mon) 12:06, Klemens Nanni wrote: > > On Sun, Jan 16, 2022 at 09:22:50AM -0300, Martin Pieuchot wrote: > > > IMHO this approach of let's try if it works now and revert if it isn't > > > do

Re: unlock mmap(2) for anonymous mappings

2022-01-24 Thread Klemens Nanni
On Sun, Jan 16, 2022 at 09:22:50AM -0300, Martin Pieuchot wrote: > IMHO this approach of let's try if it works now and revert if it isn't > doesn't help us make progress. I'd be more confident seeing diffs that > assert for the right lock in the functions called by uvm_mapanon() and >

Re: dt: make vmm tracepoints amd64 only

2022-01-24 Thread Klemens Nanni
On Mon, Jan 17, 2022 at 04:51:37PM -0800, Philip Guenther wrote: > On Mon, Jan 17, 2022 at 5:02 AM Klemens Nanni wrote: > > > These don't hurt on !VMM architectures but I was still surprised to see > > them on e.g. sparc64: > > > > # arch -s ; btrace -l

Re: 'pseudo-device dt' on macppc

2022-01-21 Thread Klemens Nanni
On Tue, Jan 18, 2022 at 07:59:20AM +0300, Andrew Krasavin wrote: > Hello! > > Is there a reason not to enable dt(4) on macppc by default? I have > built a kernel with dt enabled for test purposes and it seems to work > correctly - commands like 'btrace /usr/share/btrace/kprofile.bt' > work and I

Re: btrace: print probes sorted by name not internal id

2022-01-17 Thread Klemens Nanni
On Tue, Jan 18, 2022 at 01:03:04AM +0100, Alexander Hall wrote: > On Mon, Jan 17, 2022 at 02:23:52PM +0000, Klemens Nanni wrote: > > I keep doing `btrace -l | sort' to help myself searching for traces. > > > > Would it be worh making btrace sort the list of probes

DDBPROF: move option to amd64,i386 GENERIC

2022-01-17 Thread Klemens Nanni
While intended for more architectures, DDBPROF is strictly amd64 and i386 only, so the machine-independent sys/conf/GENERIC does not seem fit (until all architectures are supported). Index: conf/GENERIC === RCS file:

btrace: print probes sorted by name not internal id

2022-01-17 Thread Klemens Nanni
I keep doing `btrace -l | sort' to help myself searching for traces. Would it be worh making btrace sort the list of probes lexicographically in the first place or is there any value in seeing them sorted by id? Index: btrace.c ===

dt: make vmm tracepoints amd64 only

2022-01-17 Thread Klemens Nanni
These don't hurt on !VMM architectures but I was still surprised to see them on e.g. sparc64: # arch -s ; btrace -l | grep vmm sparc64 tracepoint:vmm:guest_enter tracepoint:vmm:guest_exit Like some network drivers, we could use __amd64__ to limit those to amd64

uvm_flush: return int, sync with netbsd

2022-01-17 Thread Klemens Nanni
One small mechanical diff to get rid of the boolean_t signature and reduce difference to NetBSD. uvm_flush() aka. uao_flush()/udv_flush()/pgo_flush()/uvn_flush() returns TRUE/FALSE only to make uvm_map_clean() conditionally return EFAULT. This makes the *_flush() return 0/EFAULT themselves and

Re: fw_update(8) improve verbose output

2022-01-16 Thread Klemens Nanni
On Wed, Jan 05, 2022 at 05:36:42PM -0800, Andrew Hewus Fresh wrote: > After getting fw_update(8) into a state where it could get some testing, > I found that the man page indicated that -v should indicate different > levels of verbosity and I currently only had one. > > This was useful as I

Re: unlock mmap(2) for anonymous mappings

2022-01-11 Thread Klemens Nanni
On Wed, Jan 12, 2022 at 02:32:31AM +0300, Vitaliy Makkoveev wrote: > Does it make sense to document that kernel lock protects > `ps_wxcounter’? We have such [K] in other structure definitions. > > + u_int64_t ps_wxcounter; /* [K] number of W^X violations */ Yes, that would be in

Re: unlock mmap(2) for anonymous mappings

2022-01-11 Thread Klemens Nanni
On Tue, Jan 11, 2022 at 09:54:44AM -0700, Theo de Raadt wrote: > > Now this is clearly a "slow" path. I don't think there is any reason > > not to put all the code in that if (uvw_wxabort) block under the > > kernel lock. For now I think making access to ps_wxcounter atomic is > > just too fine

Re: unlock mmap(2) for anonymous mappings

2022-01-11 Thread Klemens Nanni
On Mon, Jan 10, 2022 at 12:06:44PM +, Klemens Nanni wrote: > On Fri, Dec 31, 2021 at 07:54:53PM +0300, Vitaliy Makkoveev wrote: > > The uvm_wxabort path within uvm_wxcheck() looks not MP-safe. > > Right, I did not pay enough attention to W^X handling. New diff, either

Re: unlock mmap(2) for anonymous mappings

2022-01-10 Thread Klemens Nanni
On Fri, Dec 31, 2021 at 09:54:23AM -0700, Theo de Raadt wrote: > >Now that mpi has unlocked uvm's fault handler, we can unlock the mmap > >syscall to handle MAP_ANON without the big lock. > ... > >So here's a first small step. I've been running with this for months > >on a few amd64, arm64 and

Re: unlock mmap(2) for anonymous mappings

2022-01-10 Thread Klemens Nanni
ock or atomic operations. The kernel lock could be pushed into uvm_wxabort() but there it'd still be grabbed for every mmap(2) call. > > > On 31 Dec 2021, at 12:14, Klemens Nanni wrote: > > > > Now that mpi has unlocked uvm's fault handler, we can unlock the mmap > > sysc

unlock mmap(2) for anonymous mappings

2021-12-31 Thread Klemens Nanni
Now that mpi has unlocked uvm's fault handler, we can unlock the mmap syscall to handle MAP_ANON without the big lock. sys_mmap() still protects the !MAP_ANON case, i.e. file based mappings, with the KERNEL_LOCK() itself, which is why unlocking the syscall will only change locking behaviour for

Re: sndiod: -F does not switch back to preferred device

2021-12-25 Thread Klemens Nanni
On Sat, Dec 25, 2021 at 04:45:11PM +0100, Alexandre Ratchov wrote: > On Sat, Dec 25, 2021 at 02:51:08PM +0000, Klemens Nanni wrote: > > > > either "devices that are" or "device that is", I'd say the latter. > > > > commited with "dev

Re: sndiod: -F does not switch back to preferred device

2021-12-25 Thread Klemens Nanni
On Sat, Dec 25, 2021 at 03:46:48PM +0100, Alexandre Ratchov wrote: > On Sat, Dec 25, 2021 at 01:34:19PM +0000, Klemens Nanni wrote: > > > > This reads OK kn, but I suspect others will object to the hotplugd(8) > > reference. > > > > here's a new one, with atta

Re: sndiod: -F does not switch back to preferred device

2021-12-25 Thread Klemens Nanni
On Mon, Dec 20, 2021 at 10:11:25AM +0100, Alexandre Ratchov wrote: > On Fri, Dec 17, 2021 at 07:11:41PM +0000, Klemens Nanni wrote: > > > > So we've concluded that the hotplpugging framework needs work, fine. > > > > I'd still like to improve sndiod(8) regarding its

Re: ip_deliver without kernel lock

2021-12-24 Thread Klemens Nanni
On Fri, Dec 24, 2021 at 11:17:46PM +0100, Alexander Bluhm wrote: > ip_deliver() has been called without kernel lock from ip_ours() and > ip6_ours() for a long time. It looks like these two callers in ip6 > input were forgotten to be unlocked. OK kn

Re: : provide ElfW() macro

2021-12-18 Thread Klemens Nanni
On Sat, Dec 18, 2021 at 04:37:17PM +0300, Andrew Krasavin wrote: > On Fri, Dec 17, 2021 at 01:04:35PM +0000, Klemens Nanni wrote: > > An upcoming port uses ElfW(). I first patched the port, but looking > > around shows that both NetBSD and FreeBSD adopted the macro: > &

Re: sndiod: -F does not switch back to preferred device

2021-12-17 Thread Klemens Nanni
On Thu, Dec 09, 2021 at 11:29:04PM +, Klemens Nanni wrote: > On Thu, Dec 09, 2021 at 10:21:56AM +0100, Alexandre Ratchov wrote: > > On Wed, Dec 08, 2021 at 10:30:08PM +, Klemens Nanni wrote: > > > Following https://www.openbsd.org/faq/faq13.html#usbaudio and reading

: provide ElfW() macro

2021-12-17 Thread Klemens Nanni
An upcoming port uses ElfW(). I first patched the port, but looking around shows that both NetBSD and FreeBSD adopted the macro: https://mail-index.netbsd.org/source-changes-hg/2018/07/31/msg027523.html +#defineElfW(x) CONCAT(Elf,CONCAT(ELFSIZE,CONCAT(_,x)))

Re: sndiod: -F does not switch back to preferred device

2021-12-09 Thread Klemens Nanni
On Thu, Dec 09, 2021 at 10:21:56AM +0100, Alexandre Ratchov wrote: > On Wed, Dec 08, 2021 at 10:30:08PM +0000, Klemens Nanni wrote: > > Following https://www.openbsd.org/faq/faq13.html#usbaudio and reading > > sndiod(8)'s > > > > -F device > > S

sndiod: -F does not switch back to preferred device

2021-12-08 Thread Klemens Nanni
Following https://www.openbsd.org/faq/faq13.html#usbaudio and reading sndiod(8)'s -F device Specify an alternate device to use. If it doesn't work, the one given with the last -f or -F options will be used. For instance, specifying a USB

Re: netstart: create virtual interfaces upfront when passing specific ones

2021-12-07 Thread Klemens Nanni
On Tue, Nov 23, 2021 at 01:17:14AM +, Klemens Nanni wrote: > On Tue, Nov 16, 2021 at 11:09:40PM +0000, Klemens Nanni wrote: > > Run on boot without arguments, netstart(8) creates all virtual > > interfaces *for which hostname.if files exist* before configuring them. > &g

Re: Please test: UVM fault unlocking (aka vmobjlock)

2021-12-02 Thread Klemens Nanni
On Mon, Nov 29, 2021 at 10:50:32PM +0100, Martin Pieuchot wrote: > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > Diff below unlock the bottom part of the UVM fault handler. I'm > > interested in squashing the remaining bugs. Please test with your usual > > setup & report back. > > Thanks

Re: ipsec useless inner header

2021-12-02 Thread Klemens Nanni
On Thu, Dec 02, 2021 at 01:24:36AM +0100, Alexander Bluhm wrote: > ipsec_common_input_cb() extracts the inner IP header of IPsec > tunnels. It is never used, so this is useless code. OK kn

hotplugd: do not log device de/attach

2021-12-01 Thread Klemens Nanni
Just enabled hotplugd(8) to handle a single device I'm interested in and saw it basically duplicating kernel de/attach messages in /var/log/daemon: Dec 1 23:36:27 eru hotplugd[26475]: started Dec 1 23:36:27 eru hotplugd[26475]: uhidev4 attached, class 0 Dec 1 23:36:27 eru hotplugd[26475]:

Re: sppp(4)/pppoe(4) - avoid endless loop in remote ip negotiation

2021-12-01 Thread Klemens Nanni
On Fri, Nov 26, 2021 at 01:35:14PM +0100, Krzysztof Kanas wrote: > Hi. When remote side in sppp doesn't reply for to PPP IPCP IP-Address > sppp will try to negotiate remote IP in endless loop. Instead use > 10.64.64.1 + if_index as remote IP. Why add some arbitrary RFC 1918 IP if negotiation

Re: slaacd(8): prevent crash when interface disappears

2021-11-28 Thread Klemens Nanni
On Thu, Nov 18, 2021 at 09:02:00AM +0100, Florian Obser wrote: > This is split in two for easier review and I also intend to commit it > like this. > > The first diff shuffles setting of if_index around so that it's > available in all switch cases and uses it consistently instead of >

Re: vport: set UP on ip assign

2021-11-23 Thread Klemens Nanni
On Wed, Nov 24, 2021 at 02:30:08AM +0100, Klemens Nanni wrote: > On Tue, Nov 16, 2021 at 09:22:26AM +1000, David Gwynne wrote: > > On Mon, Nov 15, 2021 at 02:31:42PM +, Klemens Nanni wrote: > > > On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote: > >

Re: vport: set UP on ip assign

2021-11-23 Thread Klemens Nanni
On Tue, Nov 16, 2021 at 09:22:26AM +1000, David Gwynne wrote: > On Mon, Nov 15, 2021 at 02:31:42PM +0000, Klemens Nanni wrote: > > On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote: > > > On 2021/11/15 12:27, Klemens Nanni wrote: > > > > On Sun, No

Re: netstart: create virtual interfaces upfront when passing specific ones

2021-11-22 Thread Klemens Nanni
On Tue, Nov 16, 2021 at 11:09:40PM +, Klemens Nanni wrote: > Run on boot without arguments, netstart(8) creates all virtual > interfaces *for which hostname.if files exist* before configuring them. > > This prevents ordering problems with bridges and its members, as dlg's >

Re: Print learned DNS from sppp(4) in ifconfig(8)

2021-11-17 Thread Klemens Nanni
On Wed, Nov 17, 2021 at 08:51:38AM +0100, Bjorn Ketelaars wrote: > Like umb(4), sppp(4) natively learns DNS information. Among the > differences between these two devices is that umb prints this > information from ifconfig(8) and sppp does not. I would like to equalize > this behaviour, and add

netstart: create virtual interfaces upfront when passing specific ones

2021-11-16 Thread Klemens Nanni
Run on boot without arguments, netstart(8) creates all virtual interfaces *for which hostname.if files exist* before configuring them. This prevents ordering problems with bridges and its members, as dlg's commit message from 2018 reminds us. But it also helps interface types like pair(4) which

Re: vport: set UP on ip assign

2021-11-15 Thread Klemens Nanni
On Mon, Nov 15, 2021 at 04:25:54PM -0700, Theo de Raadt wrote: > > + _cmds[${#_cmds[*]}]="ifconfig $_if $_ifup" > > I will be surprised if you can simply add "up" to potential > ifconfig commandlines. This does not amend "ifconfig foo0 bar ..." to ifconfig foo0 bar ... up" if that's what

Re: vport: set UP on ip assign

2021-11-15 Thread Klemens Nanni
On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote: > On 2021/11/15 12:27, Klemens Nanni wrote: > > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote: > > > I think physical interfaces should come up when something is configured > > > on t

Re: vport: set UP on ip assign

2021-11-15 Thread Klemens Nanni
ostname.em0 will do the trick but hostname.vport0 would need another "up" for the same behaviour: that's rather confusing me as a user. > David Gwynne wrote: > > > On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote: > > > Practically all interfaces pull

Re: vport: set UP on ip assign

2021-11-15 Thread Klemens Nanni
On Mon, Nov 15, 2021 at 12:00:18PM +1000, David Gwynne wrote: > On Sat, Nov 13, 2021 at 11:59:59PM +0000, Klemens Nanni wrote: > > Practically all interfaces pull itself up when IPs get assigned, but > > vport(4) does not. > > Yes, I do (or don't do) this very deliberately

Re: let dhcpd start on down interfaces

2021-11-15 Thread Klemens Nanni
On Mon, Nov 15, 2021 at 02:08:33PM +1000, David Gwynne wrote: > The subject line only tells half the story. The other half is that > instead of hoping it only identifies Ethernet interfaces it now actually > checks and restricts itself to Ethernet interfaces. I couldn't help > myself. > > If it

ifconfig.8: autoconf implies up

2021-11-13 Thread Klemens Nanni
Since march 2021 setting AUTOCONF{4,6} sets UP as well unconditionally. I have lots of hostname.if files containing only "inet6 autoconf" without "up" and it works, but I noticed this isn't documented anywhere. Neither do we remove UP and/or RUNNING on `-autoconf' and neither do we document this.

vport: set UP on ip assign

2021-11-13 Thread Klemens Nanni
Practically all interfaces pull itself up when IPs get assigned, but vport(4) does not. This broke IPv4 networking for me on a router I switched from bridge(4) to veb(4) because hostname.vport0 only contained the equivalent of descr LAN inet 192.0.2.1 inet6 2001:db8::1

Re: installer: prompt for WEP only if available

2021-11-13 Thread Klemens Nanni
On Tue, Nov 02, 2021 at 05:43:03PM +, Klemens Nanni wrote: > On Tue, Nov 02, 2021 at 05:26:17PM +0000, Klemens Nanni wrote: > > At least bwfm(4) does not support WEP: > > > > # ifconfig bwfm0 nwkey 12345 > > ifconfig: SIOCS80211NWKEY: Operat

Re: make.1: sync variable substitution bits with NetBSD

2021-11-13 Thread Klemens Nanni
On Sat, Dec 26, 2020 at 05:19:55PM +0100, Klemens Nanni wrote: > Our make(1) is behind NetBSD's and FreeBSD's make(1) on at least the > rules of variable substitution. > > Our DESCRIPION says > > There are seven different types of lines in a makefile: dependency lines, >

Re: [PATCH] [src] share/man/man5/hostname.if.5 - nwid -> join

2021-11-11 Thread Klemens Nanni
On Thu, Nov 11, 2021 at 08:13:13PM +, Jason McIntyre wrote: > i don;t think this bit of text works well now because you say it runs > ifconfig 3 times then ... respectively. but you only list two things > (even though i understand dynamic config is two). since your text is > already clear, i'd

Re: [PATCH] [src] share/man/man5/hostname.if.5 - nwid -> join

2021-11-11 Thread Klemens Nanni
On Thu, Nov 11, 2021 at 05:48:24PM +, Stuart Henderson wrote: > On 2021/11/11 16:30, Klemens Nanni wrote: > > On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote: > > > Hello, > > > > > > It seems like this has been missed in recent thread[0]. &g

Re: amd4/bsd.rd: make "config -e" work

2021-11-11 Thread Klemens Nanni
On Thu, Nov 04, 2021 at 10:49:46PM +, Klemens Nanni wrote: > amd64, alpha, i386 and macppc strip all symbols off the ramdisk bsd.rd > (before gzipping it) and thus break config(8)'s modification feature: > > $ gzcat bsd.rd > bsd.rd.raw > $ config -e bsd.rd.r

Re: [PATCH] [src] share/man/man5/hostname.if.5 - nwid -> join

2021-11-11 Thread Klemens Nanni
On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote: > Hello, > > It seems like this has been missed in recent thread[0]. > > Not entirely sure whether the sentence "flows" any longer but here > it goes anyway. > > [0] https://marc.info/?l=openbsd-tech=163507448118443=2 Thanks, I

Re: Teach manpages of resolv(8) and unwindctl(8) about sppp(4)

2021-11-11 Thread Klemens Nanni
On Thu, Nov 11, 2021 at 07:01:42AM +0100, Bjorn Ketelaars wrote: > On Wed 10/11/2021 21:20, Klemens Nanni wrote: > > I think only unwind(8) should list all the inputs and unwindctl(8) > > should just say "Show learned nameservers". > > > > unwind(8) is al

Re: Teach manpages of resolv(8) and unwindctl(8) about sppp(4)

2021-11-10 Thread Klemens Nanni
On Wed, Nov 10, 2021 at 04:28:10PM +0100, Bjorn Ketelaars wrote: > Like umb(4), sppp(4) is natively learning DNS information. Diff below > adds this information to the manpages of resolv(8) and unwindctl(8). > While here, also mention umb(4) in unwindctl's manpage. > > Thanks to kn@ for noticing

Re: sppp(4)/pppoe(4) - DNS configuration via resolvd(8)

2021-11-10 Thread Klemens Nanni
On Wed, Nov 10, 2021 at 07:35:26AM +0100, Bjorn Ketelaars wrote: > On Mon 08/11/2021 11:52, Bjorn Ketelaars wrote: > > Diff below does two things: > > 1. add PPP IPCP extensions for name server addresses (rfc1877) to > >sppp(4) > > 2. propose negotiated name servers from sppp(4) to resolvd(8)

Re: arm64: new gpiokeys(4)

2021-11-10 Thread Klemens Nanni
On Wed, Nov 10, 2021 at 12:07:37AM +0100, Jan Stary wrote: > On Nov 09 15:43:04, k...@openbsd.org wrote: > > This populates `systat sensors' with the correct lid status on my > > Pinebook Pro: > > > > -gpio-key-lid at mainbus0 not configured > > -gpio-key-power at mainbus0 not configured

Re: rpki-client ip_addr_print cleanup

2021-11-09 Thread Klemens Nanni
On Tue, Nov 09, 2021 at 08:05:10PM +0100, Claudio Jeker wrote: > On Tue, Nov 09, 2021 at 07:44:41PM +0100, Claudio Jeker wrote: > > ip_addr_print() can be simplified. ip4_addr2str() and ip6_addr2str() are > > the same apart from the different AF argument to inet_ntop(). Just collaps > > all into

Re: rpki-client sync http escape handling with ftp(1)

2021-11-09 Thread Klemens Nanni
On Tue, Nov 09, 2021 at 07:52:06PM +0100, Claudio Jeker wrote: > kn@ removed '~' from unsafe_chars but also changed the code at the same > time. This tries to bring the version in rpki-client back in sync with the > code in ftp(1). Didn't know there was such a copy. OK kn

arm64: new gpiokeys(4)

2021-11-09 Thread Klemens Nanni
2820ebd7692d7efbe17ceae (mode 644) --- /dev/null +++ share/man/man4/gpiokeys.4 @@ -0,0 +1,50 @@ +.\"$OpenBSD: $ +.\" +.\" Copyright (c) 2021 Klemens Nanni +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fe

Re: regress/rpki-client: test openssl in regress target only

2021-11-08 Thread Klemens Nanni
On Mon, Nov 08, 2021 at 12:59:51AM +0100, Theo Buehler wrote: > > rpki-client seems to be the one-off under regress/ in this regard. > > Maybe. I wish I had a better idea than this There is: pull the test into the proper Makefile as done in regress/sys/net/inetinet/pmtu/Makefile and not

Re: sppp(4)/pppoe(4) - DNS configuration via resolvd(8)

2021-11-08 Thread Klemens Nanni
On Mon, Nov 08, 2021 at 11:52:52AM +0100, Bjorn Ketelaars wrote: > Diff below does two things: > 1. add PPP IPCP extensions for name server addresses (rfc1877) to >sppp(4) You could add that RFC to sppp(4)'s STANDARDS section. > 2. propose negotiated name servers from sppp(4) to resolvd(8)

Re: regress/rpki-client: test openssl in regress target only

2021-11-07 Thread Klemens Nanni
On Sun, Nov 07, 2021 at 11:33:29PM +0100, Theo Buehler wrote: > On Sun, Nov 07, 2021 at 10:28:22PM +0000, Klemens Nanni wrote: > > On Sun, Nov 07, 2021 at 11:16:57PM +0100, Theo Buehler wrote: > > > On Sun, Nov 07, 2021 at 10:13:44PM +0000, Klemens Nanni wrote: > > > &

armv7 and arm64 media: fail on missing packages

2021-11-07 Thread Klemens Nanni
I built arm64 media on a new machine and forgot to install firmware from packages. It took me some digging to find out which packages these were, plus it failed in the middle of the build rather than up-front. While here, I noticed that arm64 does not use the "dtb" package like armv7 does, but

Re: regress/rpki-client: test openssl in regress target only

2021-11-07 Thread Klemens Nanni
On Sun, Nov 07, 2021 at 11:16:57PM +0100, Theo Buehler wrote: > On Sun, Nov 07, 2021 at 10:13:44PM +0000, Klemens Nanni wrote: > > Spotted in `make obj' from /usr/src: > > > > ===> regress/usr.sbin/rpki-client/libressl > > /usr/src/regress/usr.sbin/rpki-cl

regress/rpki-client: test openssl in regress target only

2021-11-07 Thread Klemens Nanni
Spotted in `make obj' from /usr/src: ===> regress/usr.sbin/rpki-client/libressl /usr/src/regress/usr.sbin/rpki-client/libressl/obj -> /usr/obj/regress/usr.sbin/rpki-client/libressl Run "pkg_add openssl--%1.1" to run tests against OpenSSL 1.1 SKIPPED ===>

Re: ftp: Print actually requested URLs

2021-11-06 Thread Klemens Nanni
On Sat, Nov 06, 2021 at 07:02:39PM +, Stuart Henderson wrote: > On 2021/11/06 17:29, Klemens Nanni wrote: > > Encoding URL paths changes the requested URL and therefore may yield > > different responses (opposed to an unencoded URL), solely depending on > > how the

Re: better audio defaults: please test

2021-11-06 Thread Klemens Nanni
On Thu, Nov 04, 2021 at 04:21:12PM +0100, Alexandre Ratchov wrote: > The current sndiod latency (minimum time between when the program > plays something and when sound reaches Joe's ears) is too large and > makes OpenBSD unpleasant to use for telephony, games, and makes > controls of video players

Re: ftp: Print actually requested URLs

2021-11-06 Thread Klemens Nanni
On Sat, Nov 06, 2021 at 11:33:21AM -0600, Theo de Raadt wrote: > > This matches exactly what is seen on the wire, e.g. with tshark(1). > > I don't see why this is important. Users don't need to see what is > on the wire. > > Why intentionaly expose them to a translation they are not supposed >

ftp: Print actually requested URLs

2021-11-06 Thread Klemens Nanni
Encoding URL paths changes the requested URL and therefore may yield different responses (opposed to an unencoded URL), solely depending on how the server implements de/encoding. Thus it is imperative to inform users about the factually requested URL in case servers behave unexpectedly. Consider

Re: new site.8: document site*.tgz and /{upgrade,install}.site

2021-11-05 Thread Klemens Nanni
On Fri, Nov 05, 2021 at 05:36:48PM -0700, Andrew Hewus Fresh wrote: > I like it, some comments in-line but overall I think this would have > helped me get started with siteXX stuff, so OK afresh1@ Great, I'll commit with tweaks as per below, thanks! > > +If existent and executable, > > This

ftp: do not URI encode tilde as per RFC 2396

2021-11-05 Thread Klemens Nanni
ftp(1) implements RFC 1738 from Dec. 1994 but RFC 2396 from Aug. 1998 updated this and the tl;dr is: do not encode the tilde character. In theory, this shouldn't make a difference as servers should decode "%7e" to "~", BUT not all servers do so and thus some respond with 404. I've hit this in

Re: new site.8: document site*.tgz and /{upgrade,install}.site

2021-11-05 Thread Klemens Nanni
On Wed, Oct 27, 2021 at 07:35:28PM -0500, Aaron Poffenberger wrote: > Looks good. Nice to see this moving forward. Thanks. > > On 2021-10-27 21:13 +, Klemens Nanni wrote: > > On Mon, Sep 06, 2021 at 02:29:50PM -0500, Aaron Poffenberger wrote: > > > Ping. > >

Re: amd4/bsd.rd: make "config -e" work

2021-11-04 Thread Klemens Nanni
On Thu, Nov 04, 2021 at 10:49:46PM +, Klemens Nanni wrote: > amd64, alpha, i386 and macppc strip all symbols off the ramdisk bsd.rd > (before gzipping it) and thus break config(8)'s modification feature: > > $ gzcat bsd.rd > bsd.rd.raw > $ config -e bsd.rd.r

amd4/bsd.rd: make "config -e" work

2021-11-04 Thread Klemens Nanni
amd64, alpha, i386 and macppc strip all symbols off the ramdisk bsd.rd (before gzipping it) and thus break config(8)'s modification feature: $ gzcat bsd.rd > bsd.rd.raw $ config -e bsd.rd.raw WARNING no output file specified WARNING this kernel doesn't contain all

distrib/CDs: typofix in application ID

2021-11-04 Thread Klemens Nanni
All volume IDs use a dash and now I can't unsee it missing. OK? Index: alpha/miniroot/Makefile === RCS file: /cvs/src/distrib/alpha/miniroot/Makefile,v retrieving revision 1.23 diff -u -p -r1.23 Makefile --- alpha/miniroot/Makefile

libc/asr: remove unused variables

2021-11-04 Thread Klemens Nanni
Old diff laying around. OK? Index: libc/asr/asr.c === RCS file: /cvs/src/lib/libc/asr/asr.c,v retrieving revision 1.65 diff -u -p -r1.65 asr.c --- libc/asr/asr.c 6 Jan 2021 19:54:17 - 1.65 +++ libc/asr/asr.c 5

gpioleds: fallack to label property

2021-11-03 Thread Klemens Nanni
Some device trees such as on my Raspberry Pi 4b use the deprecated "label" property rather than "function". Fall back to it such that LEDs won't be skipped: -gpioleds0 at mainbus0: no LEDs +gpioleds0 at mainbus0: "led0", "led1" OK? Index: gpioleds.c

ifconfig: zap dead code

2021-11-02 Thread Klemens Nanni
No idea what it was supposed to do back then; cvs blame points at revision 1.19 date: 1998/09/03 06:24:18; author: jason; state: Exp; lines: +502 -38; o OpenBSD gets if_media support (from NetBSD) o rework/simplify if_xl to use OK? Index: ifconfig.c

config.8: add EXIT STATUS

2021-11-02 Thread Klemens Nanni
I looked at I had to look at the source to be sure what the three different return codes 0, 1 and 2 would mean and if there was more to it. Depending on the error, config(8) exists 1 or 2. 0 on success as usual. OK? Index: config.8

Re: ifconfig: return non-zero on failed "nwkey"

2021-11-02 Thread Klemens Nanni
On Tue, Nov 02, 2021 at 06:38:24PM +0100, Stefan Sperling wrote: > It looks like bwfm(4) does support WEP but the C_WEP capability is missing > from ic_caps so net80211 believes WEP was not supported by this driver. > > I don't think we have any supported wifi device that does not support WEP. >

Re: ifconfig: return non-zero on failed "nwkey"

2021-11-02 Thread Klemens Nanni
On Tue, Nov 02, 2021 at 11:30:11AM -0600, Theo de Raadt wrote: > Klemens Nanni wrote: > > > At least bwfm(4) does not support WEP: > > > > # ifconfig bwfm0 nwkey 12345 > > ifconfig: SIOCS80211NWKEY: Operation not supported by devi

Re: ifconfig: return non-zero on failed "nwkey"

2021-11-02 Thread Klemens Nanni
On Tue, Nov 02, 2021 at 05:26:17PM +, Klemens Nanni wrote: > At least bwfm(4) does not support WEP: > > # ifconfig bwfm0 nwkey 12345 > ifconfig: SIOCS80211NWKEY: Operation not supported by device > # echo $? > 0 > > ifconfig

ifconfig: return non-zero on failed "nwkey"

2021-11-02 Thread Klemens Nanni
At least bwfm(4) does not support WEP: # ifconfig bwfm0 nwkey 12345 ifconfig: SIOCS80211NWKEY: Operation not supported by device # echo $? 0 ifconfig(8) must return non-zero in this case. This is relevant for an upcoming installer fix, but also worth

Re: unwind.conf.5: Zap duplicate bits, mention route nameserver

2021-11-02 Thread Klemens Nanni
On Tue, Oct 26, 2021 at 01:24:30PM +, Klemens Nanni wrote: > Mentioning `route nameserver' relevance made it obvious that the > `preference' block duplicates lots of information and I despise adding > to that. route(8) is fixed/polished, unwind.conf(5) still lacks behind. >

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-30 Thread Klemens Nanni
9, 2021 at 01:59:38PM +0100: > > > On 2021/10/29 14:08, Ingo Schwarze wrote: > > >> Stuart Henderson wrote on Fri, Oct 29, 2021 at 10:53:41AM +0100: > > >>> On 2021/10/28 23:19, Klemens Nanni wrote: > > >>>> On Fri, Oct 29, 2021 at 12:57:54AM +0200,

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-28 Thread Klemens Nanni
On Fri, Oct 29, 2021 at 12:57:54AM +0200, Ingo Schwarze wrote: > MANPAGER=firefox man -T html $(ifconfig -C) This doesn't work if firefox is already running as the MANPAGER firefox process exits immediately after sending the file/link to the running process, which causes mandoc to exit after

new site.8: document site*.tgz and /{upgrade,install}.site

2021-10-27 Thread Klemens Nanni
share/man/man8/site.8 27 Oct 2021 21:11:48 - @@ -0,0 +1,87 @@ +.\" $OpenBSD: $ +.\" +.\" Copyright (c) 2021 Klemens Nanni +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby gr

Re: route.8: nameserver command is not resolvd(8) specific

2021-10-26 Thread Klemens Nanni
On Tue, Oct 26, 2021 at 04:06:20PM +0100, Jason McIntyre wrote: > On Tue, Oct 26, 2021 at 08:57:40AM -0600, Theo de Raadt wrote: > > Jason McIntyre wrote: > > > > > On Tue, Oct 26, 2021 at 12:21:52PM +, Klemens Nanni wrote: > > > > While designed to popul

unwind.conf.5: Zap duplicate bits, mention route nameserver

2021-10-26 Thread Klemens Nanni
Mentioning `route nameserver' relevance made it obvious that the `preference' block duplicates lots of information and I despise adding to that. So rearrange the list of types such that conceptually related ones are subsequent and can reference each user to not repeat things. This looks like

route.8: nameserver command is not resolvd(8) specific

2021-10-26 Thread Klemens Nanni
While designed to populate resolv.conf(5), there is nothing resolvd(8) specific about the route message route(8) sends. At least unwind(8) consumes and acts upon it; there might as well be other programs in ports that do such things, so describe it generically while going into required detail

/usr/src/*bin: remove unused variables

2021-10-25 Thread Klemens Nanni
Patrick's "bootloader: remove unsued variables" mail reminded me about this diff I still have. M sbin/vnconfig/vnconfig.c M usr.sbin/pcidump/pcidump.c M usr.sbin/wsfontload/wsfontload.c M usr.bin/less/line.c M usr.bin/make/engine.c M

Re: installer/wifi drivers: use join by default

2021-10-24 Thread Klemens Nanni
On Sun, Oct 24, 2021 at 01:24:23PM +0100, Stuart Henderson wrote: > On 2021/10/24 11:57, Klemens Nanni wrote: > > On Sun, Oct 24, 2021 at 12:41:11PM +0100, Stuart Henderson wrote: > > > On 2021/10/24 11:20, Klemens Nanni wrote: > > > > @@ -174,7 +174,7 @@ The foll

Re: installer/wifi drivers: use join by default

2021-10-24 Thread Klemens Nanni
On Sun, Oct 24, 2021 at 12:41:11PM +0100, Stuart Henderson wrote: > On 2021/10/24 11:20, Klemens Nanni wrote: > > @@ -174,7 +174,7 @@ The following > > example creates a host-based access point on boot: > > .Bd -literal -offset indent > > mediaopt hostap >

installer/wifi drivers: use join by default

2021-10-24 Thread Klemens Nanni
I reckon the adoption of `join' was fairly successful and lots of people use it exclusively, so upon install I suggest to provide hostname.if(5) using it instead of `nwid'. Likewise, reflect that trend in our driver manuals. Feedback? Objection? OK? Index: distrib/miniroot/install.sub

  1   2   3   4   5   6   7   8   9   10   >