This is macppc, goes on top of your diff from
Thu, 11 Jun 2020 16:27:03 +0300.
Do integrate this small diff into your big diff. If you need to
change the macppc code but can't build it, then do the change, and
allow me or someone else to build it. I'm gkoehler@.
macppc is a simple arch: there
Am 13.06.2020 um 22:27 schrieb jo...@armadilloaerospace.com:
> What would be a good system with CoreBoot to get for OpenBSD testing?
>
> It looks like there are some edge cases where the CoreBoot framebuffer
> support won't behave the same as the EFI framebuffer.
>
>
I'm running OpenBSD on a
On Sat, Jun 13, 2020 at 01:27:00PM -0700, jo...@armadilloaerospace.com wrote:
> What would be a good system with CoreBoot to get for OpenBSD testing?
>
> It looks like there are some edge cases where the CoreBoot framebuffer
> support won't behave the same as the EFI framebuffer.
Lots of
On 6/13/20 2:47 PM, Theo Buehler wrote:
>>> Yes. The thing is that you need to convince yourself that this is still
>>> uniformly distributed over the wanted numbers. But it's correct. In
>>> fact, it's enough to flip a fixed bit, so you can get away with one call
>>> to arc4random().
>>
>> Its
On Sat, Jun 13, 2020 at 10:41:06PM +0200, Lorenz Troiza wrote:
> Am 13.06.2020 um 22:27 schrieb jo...@armadilloaerospace.com:
> > What would be a good system with CoreBoot to get for OpenBSD testing?
> >
> > It looks like there are some edge cases where the CoreBoot framebuffer
> > support won't
On 6/13/20 9:19 AM, Theo Buehler wrote:
> On Sat, Jun 13, 2020 at 08:46:13AM -0400, David Higgs wrote:
>> On Fri, Jun 12, 2020 at 9:41 AM 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.
Remi Locherer(remi.loche...@relo.ch) on 2020.06.11 21:46:45 +0200:
> > This would be clearer if it used table/tables as appropriate e.g.
> >
> > Routing table: 0
> > Routing table: 100
> > Routing tables: 0 6 7 77
> >
> > the code to handle this gets messy though, maybe someone can think
>
> Content-Type: text/plain; charset="utf-8"
> From:
>
> What would be a good system with CoreBoot to get for OpenBSD testing?
>
> It looks like there are some edge cases where the CoreBoot framebuffer
> support won't behave the same as the EFI framebuffer.
Not sure what a good machine is, but
What would be a good system with CoreBoot to get for OpenBSD testing?
It looks like there are some edge cases where the CoreBoot framebuffer
support won't behave the same as the EFI framebuffer.
Hi,
This introduces temperature driver for the Raspberry PI 4 named bcmtmon.
bcmtmon because of bcmtemp(4) and (!strncmp("bcmt", snsrdev.xname, 4))
@kettenis has been advising me and answering questions.
bcm2711_temp.diff
Description: Binary data
On Sat, Jun 13, 2020 at 07:10:50PM -, Christian Weisgerber wrote:
> On 2020-06-13, Theo Buehler wrote:
>
> > Others have pointed out off-list that one can use __builtin_popcount(),
> > but __builtin_parity() is exactly what I want. Is it available on all
> > architectures?
>
> The standard
On 2020-06-13, Theo Buehler wrote:
> Others have pointed out off-list that one can use __builtin_popcount(),
> but __builtin_parity() is exactly what I want. Is it available on all
> architectures?
The standard implementation will be perfectly fine, no need to resort
to magic compiler
> > Yes. The thing is that you need to convince yourself that this is still
> > uniformly distributed over the wanted numbers. But it's correct. In
> > fact, it's enough to flip a fixed bit, so you can get away with one call
> > to arc4random().
>
> Its not immediately obvious because this is not
The ps_klist member of struct process can be accessed from interrupt
context as a result of signal sending. Currently, interrupts are not
blocked when ps_klist is modified, which allows race conditions.
The patch below guards ps_klist insertions and removals with splhigh().
The list should only
On Sat, 13 Jun 2020 15:19:28 +0200, Theo Buehler wrote:
> Others have pointed out off-list that one can use __builtin_popcount(),
> but __builtin_parity() is exactly what I want. Is it available on all
> architectures?
I don't think it is available on gcc 3.x for m88k but someone with
an m88k
> On 13 Jun 2020, at 10:04, Jason McIntyre wrote:
>
> On Sat, Jun 13, 2020 at 11:08:52AM +1000, David Gwynne wrote:
>>
>>
>>> 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
On Sat, Jun 13, 2020 at 08:46:13AM -0400, David Higgs wrote:
> On Fri, Jun 12, 2020 at 9:41 AM 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
On Fri, Jun 12, 2020 at 9:41 AM 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.
>
> The hash as it is now can be proved
On Sat, 13 Jun 2020 10:05:19 +0200, Martin Pieuchot wrote:
> Diff below extends the existing kqfilter handlers to be able to set
> POLLHUP in the new poll(2) implementation.
>
> __EV_HUP is introduced and now set for this purpose. A new kqfilter
> for deadfs is introduced to match the existing
And of course I still had a potential buffer overflow in there...
On Sat, 2020-06-13 at 09:16 +0200, Martijn van Duren wrote:
> Minor change: I forgot to forward the display_hint flag to
> smi_displayhint_os. Now -OQ and -Oq work as well.
>
> On Thu, 2020-06-11 at 21:17 +0200, Martijn van Duren
Diff below extends the existing kqfilter handlers to be able to set
POLLHUP in the new poll(2) implementation.
__EV_HUP is introduced and now set for this purpose. A new kqfilter
for deadfs is introduced to match the existing poll handler.
__EV_HUP is not exactly like EV_EOF. Very few
Minor change: I forgot to forward the display_hint flag to
smi_displayhint_os. Now -OQ and -Oq work as well.
On Thu, 2020-06-11 at 21:17 +0200, Martijn van Duren wrote:
> Hello Ingo,
>
> Thanks for looking into this.
>
> On Sun, 2020-05-31 at 16:32 +0200, Ingo Schwarze wrote:
> > Hi Martijn,
>
On Sat, Jun 13, 2020 at 11:08:52AM +1000, David Gwynne wrote:
>
>
> > 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
23 matches
Mail list logo
