On Sat, Jun 13, 2020 at 11:35:42AM +1000, David Gwynne wrote:
> On Fri, Jun 12, 2020 at 03:37:59PM +0200, Theo Buehler wrote:
> > I finally found the time to think about the mathematics of this some
> > more and I'm now convinced that it's a sound construction. I hope that
> > one or the other
I'm running this, seems to be working correctly.
Christian Weisgerber wrote:
> Here's a cpu_rnd_messybits() for hppa. This just steals from
> itmr_get_timecount(). If we want to use the mfctl() macro, we need
> to include into cpu.h. I don't know if we want
> that, so I went with the
On Fri, Jun 12, 2020 at 03:37:59PM +0200, Theo Buehler wrote:
> I finally found the time to think about the mathematics of this some
> more and I'm now convinced that it's a sound construction. I hope that
> one or the other observation below will be useful for you.
Yes, I read everything below
> On 13 Jun 2020, at 6:47 am, Jason McIntyre wrote:
>
> On Fri, Jun 12, 2020 at 09:53:33PM +0300, Vitaliy Makkoveev wrote:
>> Since 6.7-release npppd(8) uses pppac(4) instead of tun(4) but manual
>> page still has the reference to tun(4).
>>
>> Diff below replaced `tun' by `pppac' in
Since 6.7-release npppd(8) uses pppac(4) instead of tun(4) but manual
page still has the reference to tun(4).
Diff below replaced `tun' by `pppac' in npppd(8) man page. Also `pppac'
added to npppd.conf(5).
Index: usr.sbin/npppd/npppd/npppd.8
On Sat, Jun 13, 2020 at 12:11:13AM +0200, Mark Kettenis wrote:
> (there are some style issues with this code, but they are present in
> the libsa version as well)
Yup, various things are slightly different, but I just sticked to what's
in ofwboot/elf64_exec.c already; adjusting one for
> Date: Sat, 13 Jun 2020 00:03:14 +0200
> From: Klemens Nanni
>
> DDB's "show struct" on sparc64 does not work because the boot loader
> does not load the kernel's ELF section ".SUNW_ctf".
>
> Adapt ofwboot to do so just like libsa already does on other platforms
> (such as amd64) and therefore
DDB's "show struct" on sparc64 does not work because the boot loader
does not load the kernel's ELF section ".SUNW_ctf".
Adapt ofwboot to do so just like libsa already does on other platforms
(such as amd64) and therefore enable DDB utilise CTF information.
I needed this back when the earlier
Here's a cpu_rnd_messybits() for hppa. This just steals from
itmr_get_timecount(). If we want to use the mfctl() macro, we need
to include into cpu.h. I don't know if we want
that, so I went with the explicit asm() instead.
Completely untested.
Index: sys/arch/hppa/hppa/machdep.c
On Fri, Jun 12, 2020 at 09:53:33PM +0300, Vitaliy Makkoveev wrote:
> Since 6.7-release npppd(8) uses pppac(4) instead of tun(4) but manual
> page still has the reference to tun(4).
>
> Diff below replaced `tun' by `pppac' in npppd(8) man page. Also `pppac'
> added to npppd.conf(5).
>
hi!
this
> From: Paul Irofti
> Date: Fri, 12 Jun 2020 12:30:22 +0300
>
> On 12.06.2020 10:48, Robert Nagy wrote:
> > On 11/06/20 20:10 +0200, Mark Kettenis wrote:
> >>> Date: Thu, 11 Jun 2020 19:38:48 +0200
> >>> From: Christian Weisgerber
> >>>
> >>> Theo de Raadt:
> >>>
> The diff is growing
I finally found the time to think about the mathematics of this some
more and I'm now convinced that it's a sound construction. I hope that
one or the other observation below will be useful for you.
The hash as it is now can be proved to produce values in the full range
of uint16_t, so that's
On 12.06.2020 10:48, Robert Nagy wrote:
On 11/06/20 20:10 +0200, Mark Kettenis wrote:
Date: Thu, 11 Jun 2020 19:38:48 +0200
From: Christian Weisgerber
Theo de Raadt:
The diff is growing complexity to support a future which wouldn't
exist if attempts at *supporting all* architectures
Christian Weisgerber:
> This adds the optimized ffs(3) versions on aarch64 and powerpc to
> libc, for completeness' sake.
>
> Also add a brief regression test.
>
> OK?
Index: lib/libc/arch/aarch64/string/Makefile.inc
===
RCS file:
On 11/06/20 20:10 +0200, Mark Kettenis wrote:
> > Date: Thu, 11 Jun 2020 19:38:48 +0200
> > From: Christian Weisgerber
> >
> > Theo de Raadt:
> >
> > > The diff is growing complexity to support a future which wouldn't
> > > exist if attempts at *supporting all* architectures received priority.
15 matches
Mail list logo