Re: mbuf limit atomic operation

why? is it significantly faster? page allocation should be in the slow path. dlg > On 18 Oct 2019, at 08:33, Alexander Bluhm wrote: > > Hi, > > Can we replace the mutex that protects the mbuf allocation limit > by an atomic operation? > > ok? > > bluhm > > Index: kern/uipc_mbuf.c >

Re: [PATCH] [src] - etc/root/root.mail - correct date

Weeks too late. Raf Czlonka wrote: > Hi, > > Probably too little to late but still... > > Cheers, > > Raf > > Index: etc/root/root.mail > === > RCS file: /cvs/src/etc/root/root.mail,v > retrieving revision 1.135 > diff -u -p

[PATCH] www - 66.html - correct acpi(4) and systat(1) manual pages' sections

Hello, acpi manual page is in section 4 - device drivers - and systat in section 1 - general commands. While there, fix link to the, now removed, snmpctl(8). Regards, Raf Index: 66.html === RCS file: /cvs/www/66.html,v retrieving

[PATCH] [src] - etc/root/root.mail - correct date

Hi, Probably too little to late but still... Cheers, Raf Index: etc/root/root.mail === RCS file: /cvs/src/etc/root/root.mail,v retrieving revision 1.135 diff -u -p -r1.135 root.mail --- etc/root/root.mail 7 Oct 2019 15:34:31

mbuf limit atomic operation

Hi, Can we replace the mutex that protects the mbuf allocation limit by an atomic operation? ok? bluhm Index: kern/uipc_mbuf.c === RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.272 diff -u -p

Re: 66.html diff - Use MACHINE_ARCH consistently

Christian Weisgerber wrote: > On 2019-10-17, Brad Smith wrote: > > > -The octeon platform is now using > > +The mips64 architecture is now using > >https://man.openbsd.org/clang-local.1;>clang(1) > >as the base system compiler. > > This is wrong; sgi still uses gcc.

Re: 66.html diff - Use MACHINE_ARCH consistently

On 2019-10-17, Brad Smith wrote: > -The octeon platform is now using > +The mips64 architecture is now using >https://man.openbsd.org/clang-local.1;>clang(1) >as the base system compiler. This is wrong; sgi still uses gcc. No release has been built for sgi, but it

Re: netstart diff for aggr(4) handling

On Thu, Oct 17, 2019 at 04:47:27PM -0400, Brad Smith wrote: > Shouldn't aggr(4) be handled in the same manner as trunk(4)? I guess so, OK bluhm@ > Index: netstart > === > RCS file: /home/cvs/src/etc/netstart,v > retrieving revision

Re: Amdgpu card support

On Thu, Oct 17, 2019 at 04:42:02PM +0100, Peter Kay wrote: > First of all, thanks for including this, but should a diff be submitted > to the man page that states it supports everything between SI and Vega? > If I'm reading the documentation and past posts correctly, amdgpu uses > Xorg's Glamor

netstart diff for aggr(4) handling

Shouldn't aggr(4) be handled in the same manner as trunk(4)? Index: netstart === RCS file: /home/cvs/src/etc/netstart,v retrieving revision 1.200 diff -u -p -u -p -r1.200 netstart --- netstart29 Aug 2018 11:30:48 -

Re: 66.html diff - Use MACHINE_ARCH consistently

On 2019/10/17 16:44, Brad Smith wrote: > Fix the release notes to use MACHINE_ARCH consistently instead of > some random MACHINE mixed in. OK with me, any objections? > > > Index: 66.html > === > RCS file: /home/cvs/www/66.html,v

66.html diff - Use MACHINE_ARCH consistently

Fix the release notes to use MACHINE_ARCH consistently instead of some random MACHINE mixed in. Index: 66.html === RCS file: /home/cvs/www/66.html,v retrieving revision 1.49 diff -u -p -u -p -r1.49 66.html --- 66.html 6 Oct

Encrypted keydisk

Hi, I'm missing the ability to encrypt my keydisk with a passphrase. I'd try and implement it. Is there a suggested approach ? I'd just grab the buffer that is written to the keydisk before it's written down and encrypt it symmetrically. (using openssl?) And reverse the process for decrypting.

xhci(4): fix endless loop when transfer is aborted

My USB scanner works again in 6.6 \o/ Thanks to whoever fixed it. I have no idea when and how it happened but since a few releases back it has always been failed with some I/O error. But now it just works again as it once did (apart from a weird Xsane bug where it scans only part of the page which

Amdgpu card support

First of all, thanks for including this, but should a diff be submitted to the man page that states it supports everything between SI and Vega? If I'm reading the documentation and past posts correctly, amdgpu uses Xorg's Glamor and Mesa to output anything. Mesa is at 19.0.8, so it should support

Re: OpenBSD 6.6 release, Oct 17, 2019

Hi everyone and more specially contributors, Warm thanks for the job accomplished. Free , Functionnal and Secure for more than 20 years can be a pride for sure. I'm always happy to see GPU's code is a growing field of work in OpenBSD, as well as ARM64, keeping the project up to date in the

Re: acpithinkpad: don't take over ws_[gs]et_param on version 2 devices

On 2019-10-14, Mark Kettenis wrote: > Wo what we need to get tested is whether backlight control (stil) > works on machines that report: > > acpithinkpad0 at acpi0: version 2.0 Like my X1C5. I've tested the patches there, and they work as intended. The acpithinkpad diff causes working

ifconfig compiler warnings

Hi, I would like to fix some warings in ifconfig when compiled with WARNINGS=yes. - Move all prototypes and variables used in multiple .c files into common ifconfig.h. Basically rename brconfig.h to ifconfig.h and also use it for sff.c. - Fix missing prototypes. - Global variable s is a bad

Re: OpenBSD 6.6 release, Oct 17, 2019

Congratulations on another release and thanks for bringing us quality stuff! -ag On Thu, Oct 17, 2019 at 6:49 AM Theo de Raadt wrote: > > > - OpenBSD 6.6 RELEASED - > >

OpenBSD 6.6 release, Oct 17, 2019

- OpenBSD 6.6 RELEASED - October 17, 2019. We are pleased to announce the official release of OpenBSD 6.6. This is our 47th release. We remain proud of OpenBSD's record of

Re: rpki-client patch submission

Hi Claudio, I've picked up a manifest file from rsync://rpki-repository.nic.ad.jp/ap/A91A7381/131/L8CZI7Bafo8a3ZpZhO3BkyDbl0s.mft The original version returned (i'm at BRT/GMT-3) ~/tmp/rpki-client/test-mft -fv L8CZI7Bafo8a3ZpZhO3BkyDbl0s.mft test-mft: L8CZI7Bafo8a3ZpZhO3BkyDbl0s.mft:

Re: struct proc: track process starting time as an uptime

On Wed, 16 Oct 2019 10:23:52 -0500, Scott Cheloha wrote: > Tracking the process starting time as an uptime fixes the classic > "init(8) started in 1969" bug in ps(1) when your CMOS battery dies. > > In general it lets us track how long a process has been running > correctly regardless of whether

Re: rpki-client patch submission

On Thu, Oct 17, 2019 at 08:07:18AM -0300, Alexandre Hamada wrote: > Hi Claudio, > > Thanks for this, much appreciated. > > This is a much cleaner solution, I really liked it. > > I've tested both versions against a brand new manifest, and it is working > well. Thanks for testing. Did you

Re: rpki-client patch submission

Hi Claudio, Thanks for this, much appreciated. This is a much cleaner solution, I really liked it. I've tested both versions against a brand new manifest, and it is working well. One thing about this patch, at mft_parse_econtent() there are some unused variables left (this, next, now and

sync libc & librthread futex wrappers

Kill unused _wait() and use *_PRIVATE in both places. Using the non-private version of this interface means an extra uvm_map lookup is done. This isn't required for threads of the same process. Ok? Index: lib/libc/thread/synch.h