On Wed, Jun 06, 2018 at 08:06:30AM +0200, Remi Locherer wrote:
> Hi,
>
> RfC 5340 says that for intra area prefix LSAs metric should be set to 0
> in case of point-to-multipoint or loopback interfaces. Otherwise metric
> should be set to the value of the interfaces output cost.
>
> ospf6d curren
Functions delivering routing messages need currently the KERNEL_LOCK().
That's because routing socket/PCB states are still protected by it.
The diff below pushes the lock down by calling solock()/sounlock() inside
route_input().
As a result rtm_miss() & rtm_send() no longer need to be surrounded
Hi tech@,
The following patch fixes the build warning:
..
variable 'CFIIndex' [-Wunused-variable]
unsigned CFIIndex;
^
1 warning generated.
Index: X86FrameLowering.cpp
===
RCS file: /cvs/src/gnu/llvm/lib/Target/X
I've been finding vim with my standard settings really slow on OpenBSD.
It's been bugging me for a while, but it just took about 1.2s to open
and display a 20k patch, which was bad enough to make me dig into it
again.
I've looked at malloc options in the past and noticed that 'j' helps
but this ha
On Tue, May 29, 2018 at 06:00:12PM +0200, Daniel Cegiełka wrote:
> Hi,
>
> Sorry if this is a more "misc-list" topic, but according to
> Cryptography Services[1] team:
>
> "SPHINCS[2] is the more recent one (vs XMSS), combining a good numbers
> of advances in the field and even more! Bringing the
On Wed, Jun 06, 2018 at 09:57:14AM +0100, Stuart Henderson wrote:
> I've been finding vim with my standard settings really slow on OpenBSD.
> It's been bugging me for a while, but it just took about 1.2s to open
> and display a 20k patch, which was bad enough to make me dig into it
> again.
>
> I
On 2018/06/06 09:57, Stuart Henderson wrote:
> I've been finding vim with my standard settings really slow on OpenBSD.
> It's been bugging me for a while, but it just took about 1.2s to open
> and display a 20k patch, which was bad enough to make me dig into it
> again.
>
> I've looked at malloc o
On Tue, 05 Jun 2018 16:29:33 -0600, "Theo de Raadt" wrote:
> > + clearstr = "\033[H\033[J";
>
> I abhor increasing assumptions that the terminal honours that particular
> ANSI standard.
>
> Sorry, but at that point you have to use the libraries and get the
> information.
Or
On Wed, Jun 06, 2018 at 11:25:43AM +0100, Stuart Henderson wrote:
> On 2018/06/06 09:57, Stuart Henderson wrote:
> > I've been finding vim with my standard settings really slow on OpenBSD.
> > It's been bugging me for a while, but it just took about 1.2s to open
> > and display a 20k patch, which
Otto Moerbeek wrote:
> On Wed, Jun 06, 2018 at 11:25:43AM +0100, Stuart Henderson wrote:
>
> > On 2018/06/06 09:57, Stuart Henderson wrote:
> > > I've been finding vim with my standard settings really slow on OpenBSD.
> > > It's been bugging me for a while, but it just took about 1.2s to open
>
On Wed, Jun 06, 2018 at 09:01:49AM +0200, Claudio Jeker wrote:
> On Wed, Jun 06, 2018 at 08:06:30AM +0200, Remi Locherer wrote:
> > Hi,
> >
> > RfC 5340 says that for intra area prefix LSAs metric should be set to 0
> > in case of point-to-multipoint or loopback interfaces. Otherwise metric
> > s
Hi,
The udp control option processing is implemented 3 times. Multicast
lacks receive destination port. So better use a function and do
it all in one place.
The pipex chunk does not use the options, so it can happen before.
Adding the udp header length to the ip header length was done
inconsis
On Wed, Jun 06, 2018 at 08:17:54PM +0200, Remi Locherer wrote:
> On Wed, Jun 06, 2018 at 09:01:49AM +0200, Claudio Jeker wrote:
> > On Wed, Jun 06, 2018 at 08:06:30AM +0200, Remi Locherer wrote:
> > > Hi,
> > >
> > > RfC 5340 says that for intra area prefix LSAs metric should be set to 0
> > > in
So the announce keyword in bgpd is massivly overloaded.
It is one of the most common things new bgpd users are unsure about.
These are all possible announce options:
announce (IPv4|IPv6) (none|unicast|vpn)
announce as-4byte (yes|no)
announce capabilities (yes|no)
announce refresh (yes|no)
announce
Hi,
The output from tcp debug sockets was incomplete. After detach tp
was NULL and nothing was traced. So save the old tcpcb and use
that to retreive some information. Note that otb may be freed and
must not be dereferenced. Use a heuristic for cases where the
address family is in the IP heade
On Wed, Jun 06, 2018 at 03:57:44PM +0800, Nan Xiao wrote:
> Hi tech@,
>
> The following patch fixes the build warning:
Committed, thanks!
>
> ..
>
> variable 'CFIIndex' [-Wunused-variable]
> unsigned CFIIndex;
>^
> 1 warning generated.
>
>
> Index: X86FrameLowering.cpp
> ==
16 matches
Mail list logo
