On Fri, 18 Dec 2020 at 18:58:43 -0600, Scott Cheloha wrote:
> Hi,
>
> tpm(4) is the last driver in the tree using tvtohz(9). There are no
> remaining callers using tstohz(9), so if and when we remove tvtohz(9)
> from tpm(4) we can remove both interfaces from the tree.
>
> tpm(4) is tricky becaus
On 12/17/20 3:15 AM, Otto Moerbeek wrote:
Hi,
as noted on misc dig does not like to talk to local link addresses.
This fixes that case. While investigating I also found another bug:
selecting v6 or v4 addresses only from resolv.conf via the -4 or -6
command line argument does not work as expe
Hi,
tpm(4) is the last driver in the tree using tvtohz(9). There are no
remaining callers using tstohz(9), so if and when we remove tvtohz(9)
from tpm(4) we can remove both interfaces from the tree.
tpm(4) is tricky because it converts timeouts from milliseconds to
ticks and then doesn't use tsl
Graphics stuff is weird. It doesn't just care about endianness on the
byte level, but also about endianness on the bit level. This matters
for monochrome framebuffers, where a true big-endian framebuffer will
have the leftmost pixel in the MSB wheras a little-endian framebuffer
will have it in th
So I ended up in doas again, this time with the CFLAGS I use for most of
my other projects. This popped up a few new not very exciting warnings.
Diff below compiles clean with both clang and gcc on amd64.
Worth doing?
martijn@
Index: Makefile
=
I'm scraping the bottom of the barrel with these, so dumped them all
together for ease of review. Will submit piecemeal as reviews happen.
All verified manually with sysctl -w. Even bothered to find an i386
machine with watchdog and build a WITNESS kernel to run all code paths.
OKs?
Subject: [PA
Hi,
This patch adds support for passing NULL as the ident when calling
tsleep(9) etc. When this happens, sleep_setup() will use the address
of the sleep_state struct as the value for p_wchan. This address is
basically always a private value so the thread should never receive a
wakeup(9) broadcas
> This is the next step. I added asserts for strings that must be set and
> removed some of complications around optional strings. Especially cert.c
> and some of the entityq code benefits from this.
Looks good and works for me.
ok tb
On Fri, Dec 18, 2020 at 05:50:27PM +0100, Theo Buehler wrote:
> On Fri, Dec 18, 2020 at 05:45:01PM +0100, Claudio Jeker wrote:
> > On Fri, Dec 18, 2020 at 01:46:49PM +0100, Theo Buehler wrote:
> > > On Fri, Dec 18, 2020 at 11:43:40AM +0100, Claudio Jeker wrote:
> > > > On Wed, Dec 02, 2020 at 05:06
On Fri, Dec 18, 2020 at 05:45:01PM +0100, Claudio Jeker wrote:
> On Fri, Dec 18, 2020 at 01:46:49PM +0100, Theo Buehler wrote:
> > On Fri, Dec 18, 2020 at 11:43:40AM +0100, Claudio Jeker wrote:
> > > On Wed, Dec 02, 2020 at 05:06:28PM +0100, Claudio Jeker wrote:
> > > > rpki-client passes both empt
On Fri, Dec 18, 2020 at 01:46:49PM +0100, Theo Buehler wrote:
> On Fri, Dec 18, 2020 at 11:43:40AM +0100, Claudio Jeker wrote:
> > On Wed, Dec 02, 2020 at 05:06:28PM +0100, Claudio Jeker wrote:
> > > rpki-client passes both empty strings and NULL strings as zero length
> > > objects. The unmarshal
On Fri, 18 Dec 2020 13:34:39 +0100, Mark Kettenis wrote:
> Anyway, your analysis is right. When a kernel thread wants to use
> pmap_extract(9) on a userland pmap, it needs to lock pm_apte_mtx to
> prevent another thread from simultaniously activating a userland pmap
> too. So indeed, pm_apte_mtx
On Fri, Dec 18, 2020 at 3:53 AM Alexandr Nedvedicky
wrote:
>
> Hello Sven,
>
> your change makes me wonder: 'what is the actual problem you are trying to
> solve'?
>
> the reason I'm asking is that latency is just one factor, which contributes to
> TCP connection performance. The other factor (and
On Fri, Dec 18, 2020 at 11:43:40AM +0100, Claudio Jeker wrote:
> On Wed, Dec 02, 2020 at 05:06:28PM +0100, Claudio Jeker wrote:
> > rpki-client passes both empty strings and NULL strings as zero length
> > objects. The unmarshal code then allocates memory in any case and so a
> > NULL string is unm
> Date: Thu, 17 Dec 2020 19:25:44 -0300
> From: Martin Pieuchot
>
> On 17/12/20(Thu) 23:16, Mark Kettenis wrote:
> > > Date: Thu, 17 Dec 2020 18:56:52 -0300
> > > From: Martin Pieuchot
> > >
> > > On 16/12/20(Wed) 22:49, Greg Steuck wrote:
> > > > I just hit this while booting an i386-current i
On Fri, Dec 18, 2020 at 11:42:38AM +0100, Claudio Jeker wrote:
> On Thu, Dec 03, 2020 at 02:33:03PM +0100, Claudio Jeker wrote:
> > Use asprintf with %.*s to construct the path based on the mft file
> > location and the filename of the referenced file.
> >
> > Since the * field in printf(3) is exp
> Date: Fri, 18 Dec 2020 13:04:42 +0100
> From: Alexander Bluhm
>
> On Fri, Dec 18, 2020 at 10:36:28AM +1000, Jonathan Matthew wrote:
> > Here are a couple of relatively easy ones, applying changes from r1.86 of
> > amd64's acpi_machdep.c to i386 and arm64. I've tested i386 but it turns
> > out
On Fri, Dec 18, 2020 at 10:36:28AM +1000, Jonathan Matthew wrote:
> Here are a couple of relatively easy ones, applying changes from r1.86 of
> amd64's acpi_machdep.c to i386 and arm64. I've tested i386 but it turns out I
> don't have any arm64 machines with acpi.
A machine like this? Something
On Wed, Dec 02, 2020 at 05:06:28PM +0100, Claudio Jeker wrote:
> rpki-client passes both empty strings and NULL strings as zero length
> objects. The unmarshal code then allocates memory in any case and so a
> NULL string is unmarshalled as empty string. This is not great, currently
> there are no
On Thu, Dec 03, 2020 at 02:33:03PM +0100, Claudio Jeker wrote:
> Use asprintf with %.*s to construct the path based on the mft file
> location and the filename of the referenced file.
>
> Since the * field in printf(3) is expecting an int type, typecast the
> ptrdiff_t to an int. Add an assert che
In preparation for RTR support this diff changes the internal
representation of roa-set to a simple RB tree based on struct roa.
The big difference is that overlapping roas, e.g.
10/8 source-as 3
10/8 maxlen 24 source-as 3
are now merged in the RDE and so bgpd -nv will show both ent
Hello Sven,
your change makes me wonder: 'what is the actual problem you are trying to
solve'?
the reason I'm asking is that latency is just one factor, which contributes to
TCP connection performance. The other factor (and perhaps more important) is to
guess amount of retransmitted data. Process
22 matches
Mail list logo
