Hi,
The following diff is still without intented behaviour changes.
The first chunk replaces a direct vp->v_op->vop_lock() call by
VOP_LOCK() wrapper. It only adds some safety check on vop_lock being
NULL (and MUTEX_ASSERT_UNLOCKED on vnode_mtx).
Others chunks replaces several direct manipulatio
On Sun, Oct 03, 2021 at 10:05:56AM +, Klemens Nanni wrote:
> On Sat, Oct 02, 2021 at 07:03:21PM +0200, vifino wrote:
> > On Sat Oct 2, 2021 at 6:36 PM CEST, Raf Czlonka wrote:
> > > On Sat, Oct 02, 2021 at 02:15:53PM BST, vifino wrote:
> > > > Index: ldapd.conf.5
> > > > ===
> On Oct 14, 2021, at 18:09, Scott Cheloha wrote:
>
> On Thu, Oct 14, 2021 at 11:37:44PM +0200, Mark Kettenis wrote:
>>> Date: Thu, 14 Oct 2021 16:13:17 -0500
>>> From: Scott Cheloha
>>>
>>> [...]
>>>
>>> Thoughts?
>>
>> I never understood this code. But I don't understand that if our
>> ti
Hello tech list,
OpenBSD's libm is missing logbl(3) function on archs where long double
is double. The missing logbl breaks my builds of "NEW: devel/dtools"
(ports list) on macppc and powerpc64. I guess that other software
avoids logbl and prefers ilogbl(3) or frexp(3).
This diff adds logbl and
On Thu, Oct 14, 2021 at 11:37:44PM +0200, Mark Kettenis wrote:
> > Date: Thu, 14 Oct 2021 16:13:17 -0500
> > From: Scott Cheloha
> >
> > [...]
> >
> > Thoughts?
>
> I never understood this code. But I don't understand that if our
> timecounters are only 32 bits, we need more than 64 bits to st
> Date: Thu, 14 Oct 2021 16:13:17 -0500
> From: Scott Cheloha
>
> Hi,
>
> When we compute high resolution time, both in the kernel and in libc,
> we get a 32-bit (or smaller) value from the active timecounter and
> scale it up into a 128-bit bintime.
>
> The scaling math currently looks like th
On Mon, Oct 11, 2021 at 09:13:16AM -0500, Scott Cheloha wrote:
> On Sun, Oct 10, 2021 at 08:26:04PM -0400, gwes wrote:
> > On 10/10/21 5:03 PM, Scott Cheloha wrote:
> > > [...]
> > >
> > > If we want to have the unportable legacy syntax then it should work
> > > like other option arguments. Optio
Hi,
When we compute high resolution time, both in the kernel and in libc,
we get a 32-bit (or smaller) value from the active timecounter and
scale it up into a 128-bit bintime.
The scaling math currently looks like this in the kernel:
*bt = th->th_offset;
bintimeaddfrac(bt, th->t
On Thu, 14 Oct 2021 23:06:01 +0200, Mark Kettenis wrote:
> This doesn't work because of the hidden symbol madness. The way
> things currently are we need one copy (s_lrint.c) with:
>
> DEF_STD(fn);
> LDBL_MAYBE_CLONE(fn);
>
> another version (s_lrintf.c) with
>
> DEF_STD(fn);
>
> and a final vers
> From: "Todd C. Miller"
> Date: Thu, 14 Oct 2021 14:40:13 -0600
>
> On Thu, 14 Oct 2021 01:15:56 +0200, Mark Kettenis wrote:
>
> > Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> > and other platforms. Our implementation came from NetBSD, but NetBSD
> > switched to the
> Date: Thu, 14 Oct 2021 22:23:25 +0200
> From: Alexander Bluhm
>
> On Thu, Oct 14, 2021 at 01:15:56AM +0200, Mark Kettenis wrote:
> > Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> > and other platforms. Our implementation came from NetBSD, but NetBSD
> > switched to th
On Thu, 14 Oct 2021 01:15:56 +0200, Mark Kettenis wrote:
> Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> and other platforms. Our implementation came from NetBSD, but NetBSD
> switched to the implementation from FreeBSD some time ago. That is
> the same implementation t
On Thu, Oct 14, 2021 at 01:15:56AM +0200, Mark Kettenis wrote:
> Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> and other platforms. Our implementation came from NetBSD, but NetBSD
> switched to the implementation from FreeBSD some time ago. That is
> the same implementat
joshua stein wrote:
> On Thu, 14 Oct 2021 at 09:21:18 +0200, Stefan Hagen wrote:
> > This ramp up time is reproducible. It always starts slower in the first
> > 1 or 2 seconds and then ramps up to full speed.
>
> I've observed this in ethernet transfers on OpenBSD for a long time,
> it's not limi
On Thu, 14 Oct 2021 at 09:21:18 +0200, Stefan Hagen wrote:
> This ramp up time is reproducible. It always starts slower in the first
> 1 or 2 seconds and then ramps up to full speed.
I've observed this in ethernet transfers on OpenBSD for a long time,
it's not limited to WiFi.
OK bluhm@
> - out:
> - fdpunlock(fdp);
> +out:
With a space before the label, diff -p shows the function name and
not some label within the function. I consider this helpful when
reading diffs.
Diff below is the counterpart of the select(2) one I just committed to
make poll(2) and ppoll(2) use kqueue internally.
They use the same logic as select(2): convert pollfd into kqueue events
with EV_SET(2) then wait in kqueue_scan().
To make this implementation compatible with the existing poll(
On 12.10.2021. 16:29, Hrvoje Popovski wrote:
> On 12.10.2021. 14:47, Stefan Sperling wrote:
>> This patch adds support for 40MHz channels to iwx(4).
>>
>> Please sync your source tree before attempting to apply this patch.
>> I have committed some changes to this driver today which this patch
>> is
Stefan Sperling wrote:
> This patch adds support for 40MHz channels to iwx(4).
>
> Please sync your source tree before attempting to apply this patch.
> I have committed some changes to this driver today which this patch
> is based on.
>
> Works for me on AX200/AX201. Does anyone else want to do
19 matches
Mail list logo
