Re: fix pppx(4) with net/ifq.c rev 1.38

2020-05-25 Thread Martin Pieuchot
On 23/05/20(Sat) 15:38, Vitaliy Makkoveev wrote: > > On 23 May 2020, at 12:54, Martin Pieuchot wrote: > > On 22/05/20(Fri) 13:25, Vitaliy Makkoveev wrote: > >> On Fri, May 22, 2020 at 07:57:13AM +1000, David Gwynne wrote: > >>> [...] > >>> can you try the following diff? > >>> > >> > >> I

Re: pppx(4): avoid direct usage of pxi owned session.

2020-05-25 Thread Martin Pieuchot
On 24/05/20(Sun) 22:58, Vitaliy Makkoveev wrote: > > Please yes, remove the duplication before trying to address concurrency > > issues. It will make review easier :) > > We stopped at `pppx_ifs_lk’ removal, so let’s continue but after [1] > finished. > > 1.

vmx(4) msi-x

2020-05-25 Thread Jonathan Matthew
This prepares vmx(4) for multi-queue operation, first by making use of msi-x where available, and second by rearranging the queue structures to fit the direction we're heading in. As with other drivers, here I'm reserving msi-x vector 0 for events, then mapping tx/rx queues to the subsequent

Introduce kqueue_terminate() & kqueue_free()

2020-05-25 Thread Martin Pieuchot
Small refactoring needed to manage per-thread kqueues. Such kqueue are not associated to a file descriptor, that's why the functions below take a "struct kqueue *" as argument. ok? Index: kern/kern_event.c === RCS file:

Re: random(4): use arc4random_ctx_buf() for large device reads

2020-05-25 Thread Sebastien Marie
On Sun, May 24, 2020 at 09:33:27PM +0200, Christian Weisgerber wrote: > (This is in a different part of the file from Theo's current efforts.) > > For large reads from /dev/random, use the arc4random_ctx_*() functions > instead of hand-rolling the same code to set up a temporary ChaCha >

Re: vmd(8) and thread safety: a quick proof of concept using libevent 2.1 from ports

2020-05-25 Thread Claudio Jeker
On Mon, May 25, 2020 at 02:14:18AM -0700, Pratik Vyas wrote: > * Claudio Jeker [2020-05-25 10:14:11 +0200]: > > > The problem is that the vm exit is handled by a different thread then the > > event loop. So some event_add/evtimer_add calls are done from a different > > thread then the main event

Re: vmd(8) and thread safety: a quick proof of concept using libevent 2.1 from ports

2020-05-25 Thread Martin Pieuchot
On 24/05/20(Sun) 07:56, Dave Voutila wrote: > On Sat, May 23, 2020 at 9:38 PM Dave Voutila wrote: > > > > Hello tech@, > > > > Attached is a diff that patches vmd(8) to utilize libevent 2.1 (from > > ports) in an attempt to test the hypothesis that thread safety will > > help stabilize Linux

Re: vmd(8) and thread safety: a quick proof of concept using libevent 2.1 from ports

2020-05-25 Thread Claudio Jeker
On Mon, May 25, 2020 at 10:02:27AM +0200, Martin Pieuchot wrote: > On 24/05/20(Sun) 07:56, Dave Voutila wrote: > > On Sat, May 23, 2020 at 9:38 PM Dave Voutila wrote: > > > > > > Hello tech@, > > > > > > Attached is a diff that patches vmd(8) to utilize libevent 2.1 (from > > > ports) in an

Re: vmd(8) and thread safety: a quick proof of concept using libevent 2.1 from ports

2020-05-25 Thread Pratik Vyas
* Claudio Jeker [2020-05-25 10:14:11 +0200]: > The problem is that the vm exit is handled by a different thread then the > event loop. So some event_add/evtimer_add calls are done from a different > thread then the main event loop (mainly interrupt processing). > > One approach to fix this is

Re: vmd(8) and thread safety: a quick proof of concept using libevent 2.1 from ports

2020-05-25 Thread Martin Pieuchot
On 25/05/20(Mon) 10:14, Claudio Jeker wrote: > [...] > One approach to fix this is to ensure that the event functions are > exclusivly used in the main event thread but as usual it is easy to > introduce bugs again. This is a common issue with multi-threaded applications using non thread-safe

Re: [PATCH} efifb support for wsmoused + smaller fonts

2020-05-25 Thread Jonathan Gray
On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com wrote: > The efifb driver behaves almost identically to the inteldrm driver > for wscons, but did not implement the getchar() accessops, so > wsmoused would fail at startup. This seems reasonable, though your mail client has

Re: [PATCH} efifb support for wsmoused + smaller fonts

2020-05-25 Thread Mark Kettenis
> Date: Tue, 26 May 2020 00:27:31 +1000 > From: Jonathan Gray > > On Mon, May 25, 2020 at 08:49:23AM -0500, Lucas Raab wrote: > > On Mon, May 25, 2020 at 09:13:43PM +1000, Jonathan Gray wrote: > > > On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com > > > wrote: > > > > The

Re: Provide ldomctl(8) better error messages when parsing ldom.conf

2020-05-25 Thread Mark Kettenis
> Date: Sun, 24 May 2020 18:59:09 -0400 > From: Kurt Mosiejczuk > > Currently ldomctl init-system will error out in many situations. A number of > them involve requesting more resources than there are available. Right now > onw just gets error messages like: > > resource_id larger than

Re: [PATCH} efifb support for wsmoused + smaller fonts

2020-05-25 Thread Lucas Raab
On Mon, May 25, 2020 at 09:13:43PM +1000, Jonathan Gray wrote: > On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com wrote: > > The efifb driver behaves almost identically to the inteldrm driver > > for wscons, but did not implement the getchar() accessops, so > > wsmoused would

Re: random(4): use arc4random_ctx_buf() for large device reads

2020-05-25 Thread Sebastien Marie
On Mon, May 25, 2020 at 05:27:37PM +0200, Christian Weisgerber wrote: > Sebastien Marie: > > > > For large reads from /dev/random, use the arc4random_ctx_*() functions > > > instead of hand-rolling the same code to set up a temporary ChaCha > > > instance. > > > > Eventually, I would get ride of

pppx(4): kill useless rwlock `pppx_ifs_lk'

2020-05-25 Thread Vitaliy Makkoveev
`pppx_ifs_lk' used to protect `pppx_ifs' tree, But this tree is accessed under KERNL_LOCK() and there is no concurency. Also we don't sleep while holding this lock. So it's useless, kill it for simplification. Index: sys/net/if_pppx.c

Re: [PATCH} efifb support for wsmoused + smaller fonts

2020-05-25 Thread Mark Kettenis
> Date: Mon, 25 May 2020 21:13:43 +1000 > From: Jonathan Gray > > On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com wrote: > > The efifb driver behaves almost identically to the inteldrm driver > > for wscons, but did not implement the getchar() accessops, so > > wsmoused

pipex(4): document struct members locking

2020-05-25 Thread Vitaliy Makkoveev
This time it's not clean which lock is really required to protect pipex(4) data structures. In fact KERNL_LOCK() and NET_LOCK() are used simultaneously. It's time to document it. Only [k] used do mark mutable members due to NET_LOCK() looks be unnecesary and can be killed in future. Index:

Re: [PATCH} efifb support for wsmoused + smaller fonts

2020-05-25 Thread Jonathan Gray
On Mon, May 25, 2020 at 08:49:23AM -0500, Lucas Raab wrote: > On Mon, May 25, 2020 at 09:13:43PM +1000, Jonathan Gray wrote: > > On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com > > wrote: > > > The efifb driver behaves almost identically to the inteldrm driver > > > for

Re: sysupgrade change to allow installing from url

2020-05-25 Thread Jason McIntyre
On Mon, May 25, 2020 at 03:25:40PM +0200, Solene Rapenne wrote: > Hi, > > I don't know if this will be accepted but I propose to add a -u [url] > parameter to use older snapshots from an archive server for example. > > I wanted to add an optional parameter to -s at first but in case of >

sysupgrade change to allow installing from url

2020-05-25 Thread Solene Rapenne
Hi, I don't know if this will be accepted but I propose to add a -u [url] parameter to use older snapshots from an archive server for example. I wanted to add an optional parameter to -s at first but in case of sysupgrade -s [installurl] the install url would have been mistaken by this. If you

Re: random(4): use arc4random_ctx_buf() for large device reads

2020-05-25 Thread Christian Weisgerber
Sebastien Marie: > > For large reads from /dev/random, use the arc4random_ctx_*() functions > > instead of hand-rolling the same code to set up a temporary ChaCha > > instance. > > Eventually, I would get ride of myctx, initialize lctx to NULL, and use > (lctx == NULL) to replace (myctx == 0).

Re: kqueue_scan() refactoring

2020-05-25 Thread Martin Pieuchot
On 10/04/20(Fri) 14:43, Martin Pieuchot wrote: > Diff below reduces kqueue_scan() to the collect of events on a given > kqueue and let its caller, sys_kevent(), responsible for the copyout(9). > > Apart from the code simplification, this refactoring clearly separates > kqueue_scan() from the

Re: [patch] fuse_main.3 - fix example to compile without warnings and apply style changes

2020-05-25 Thread Jason McIntyre
On Sat, May 23, 2020 at 01:12:41PM -0500, Edgar Pettijohn wrote: > fixed, thanks. jmc > Index: fuse_main.3 > === > RCS file: /cvs/src/lib/libfuse/fuse_main.3,v > retrieving revision 1.6 > diff -u -p -u -r1.6 fuse_main.3 > ---

[RFC] ppp: add pipex(4) support

2020-05-25 Thread Sergey Ryazanov
Add minimal support for integration with pipex(4). Initialize interface structure, pass IOCTLs to pipex(4) specific handler, etc. Acceleration is working only in the DL path only at the moment. Modification is not ready for applying. Work still in process. --- sys/net/if_ppp.c| 16

[RFC] pppd: add pipex(4) L2TP control support

2020-05-25 Thread Sergey Ryazanov
Add dedicated option to activate kernel L2TP acceleration via the pipex(4). The options should be passed by a L2TP tunnel management daemon (e.g. xl2tpd). This diff is complete, but kernel support in ppp(4) is not ready. --- usr.sbin/pppd/ipcp.c| 5 +++ usr.sbin/pppd/options.c | 82

Re: WireGuard patchset for OpenBSD

2020-05-25 Thread Theo de Raadt
I'll make a comment that I am quite unhappy about this ioctl methodology. I don't like void *'s and varying sizes. I would be much happier if this was a fixed structure, filled with known objects. It looks fragile. Tobias Heider wrote: > Hi Matt, > > i finally found some time to look at

Re: [PATCH] pipex(4): rework PPP input

2020-05-25 Thread Sergey Ryazanov
Hello Vitaliy, On Sat, May 23, 2020 at 3:07 PM Vitaliy Makkoveev wrote: > > On 23 May 2020, at 13:11, Sergey Ryazanov wrote: > > On Wed, May 20, 2020 at 10:13 PM Vitaliy Makkoveev > > wrote: > >> On Wed, May 20, 2020 at 04:08:01AM +0300, Sergey Ryazanov wrote: > >>> On Tue, May 19, 2020 at

Re: WireGuard patchset for OpenBSD

2020-05-25 Thread Tobias Heider
Hi Matt, i finally found some time to look at your diff and it looks pretty good to me so far. I have a few question about the SIOCGWG ioctl. > +void > +wg_status(void) > +{ > + size_t i, j, size = 0; > + struct timespec now; > + char

Ncurses: issue with "rep" capability and --enable-bsdpad (BSD_TPUTS)

2020-05-25 Thread Hiltjo Posthuma
Hi, I've noticed an issue when testing the "rep" capability to st (terminal emulator) on OpenBSD. After some digging I found the issue is when BSD_TPUTS is defined (ncurses_cfg.h). This enables code for BSD prefix padding and a workaround for nethack and ancient BSD terminals as the C comment

TP-Link TL-WN822N-EU v5 USB ID

2020-05-25 Thread Tero Koskinen
Hi, I have TP-Link TL-WN822N-EU v5 USB adapter[1] with USB VID/PID 2357:0108: $ usbdevs Controller /dev/usb0: addr 01: 1022: AMD, xHCI root hub addr 02: 2357:0108 Realtek, 802.11n NIC Controller /dev/usb1: addr 01: 1022: AMD, EHCI root hub addr 02: 0438:7900 Advanced Micro Devices, Hub $

Re: Provide ldomctl(8) better error messages when parsing ldom.conf

2020-05-25 Thread Klemens Nanni
On Mon, May 25, 2020 at 05:55:39PM +0200, Mark Kettenis wrote: > Including numbers is good! I feel, quite strongly, that lowercase > vcpu isn't right. So please use VCPU (or plural VCPUs) instead. I > also think that your proposal is a bit inconsistent regarding > and > "larger than". So: > >

Re: WireGuard patchset for OpenBSD

2020-05-25 Thread Jason A. Donenfeld
On Mon, May 25, 2020 at 2:16 PM Theo de Raadt wrote: > > I'll make a comment that I am quite unhappy about this ioctl > methodology. I don't like void *'s and varying sizes. > > I would be much happier if this was a fixed structure, filled with > known objects. > > It looks fragile. Indeed the

Re: locale thread support

2020-05-25 Thread Ingo Schwarze
Hi, my impression is there are two totally independent topics in this thread. 1. Whether and how to make things safer, ideally terminating the program in a controlled manner, if it uses functions that are not thread-safe in an invalid manner. I'm not addressing that topic in this

Re: sysupgrade change to allow installing from url

2020-05-25 Thread Sebastian Benoit
Solene Rapenne(sol...@perso.pw) on 2020.05.25 15:25:40 +0200: > Hi, > > I don't know if this will be accepted but I propose to add a -u [url] > parameter to use older snapshots from an archive server for example. > > I wanted to add an optional parameter to -s at first but in case of >