On Thu, Mar 04, 2021 at 03:36:19PM +1000, David Gwynne wrote:
> as the subject says, this is a rewrite of vxlan(4).
>
> vxlan(4) relies on bridge(4) to implement learning, but i want to be
> able to remove bridge(4) one day. while working on veb(4), i wrote
> the guts of a learning bridge
Hi,
I have reworked my proposed interface for sticky displays in systat
following earlier feedback. Thanks for that! It helped me rethink the
interface carefully.
In the current version, sticky mode has its own toggle: ^T. From a study
of the source and the man page it does not seem to be bound
this passes the destination ethernet address from the network packet
as a uint64_t from ether_input into carp_input, so it can use it
to see if a carp interface should take the packet.
it's been working on amd64 and sparc64. anyone else want to try?
Index: netinet/ip_carp.c
On Thu, Mar 04, 2021 at 04:25:53PM +0100, Theo Buehler wrote:
> On Thu, Mar 04, 2021 at 04:10:12PM +0100, Claudio Jeker wrote:
> > On Thu, Mar 04, 2021 at 03:53:44PM +0100, Theo Buehler wrote:
> > > The first two seem obvious oversights. The ones in rsync_base_uri()
> > > would end up silently
On Thu, Mar 04, 2021 at 04:10:12PM +0100, Claudio Jeker wrote:
> On Thu, Mar 04, 2021 at 03:53:44PM +0100, Theo Buehler wrote:
> > The first two seem obvious oversights. The ones in rsync_base_uri()
> > would end up silently ignored:
> > queue_add_from_cert
> > repo_lookup
> > rsync_base_uri
>
On Thu, Mar 04, 2021 at 03:53:44PM +0100, Theo Buehler wrote:
> The first two seem obvious oversights. The ones in rsync_base_uri()
> would end up silently ignored:
> queue_add_from_cert
> repo_lookup
> rsync_base_uri
>
> Index: http.c
>
The first two seem obvious oversights. The ones in rsync_base_uri()
would end up silently ignored:
queue_add_from_cert
repo_lookup
rsync_base_uri
Index: http.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
retrieving
On Thu, Mar 04, 2021 at 10:06:24PM +1000, David Gwynne wrote:
> this applies the tricks with addresses from veb and etherbridge
> code to the normal ethernet input processing. it seems to make
> things a bit faster. some tests have shown a 15% improvement in
> forwarding performance with this
On Thu, Mar 04, 2021 at 11:06:21AM +0100, Martin Pieuchot wrote:
> On 04/03/21(Thu) 10:36, Claudio Jeker wrote:
> > On Thu, Mar 04, 2021 at 10:28:50AM +0100, Martin Pieuchot wrote:
> > > SINGLE_PTRACE has almost the same semantic as SINGLE_SUSPEND. The
> > > difference is that there's no need to
Works fine here, OK florian
On Wed, Mar 03, 2021 at 08:50:59PM -0300, Fernando Gont wrote:
> This revised patch adresses a minor issue pointed out by Florian (avoid
> floating-point math). At this point this is unnecessary, since the
> IPv6 temporary address lifetimes are not configurable.
>
>
> Date: Thu, 4 Mar 2021 11:19:23 +0100
> From: Martin Pieuchot
>
> On 04/03/21(Thu) 11:01, Mark Kettenis wrote:
> > > Date: Thu, 4 Mar 2021 10:54:48 +0100
> > > From: Patrick Wildt
> > >
> > > Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark Kettenis:
> > > > > Date: Thu, 4 Mar 2021
On 04/03/21(Thu) 11:01, Mark Kettenis wrote:
> > Date: Thu, 4 Mar 2021 10:54:48 +0100
> > From: Patrick Wildt
> >
> > Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark Kettenis:
> > > > Date: Thu, 4 Mar 2021 10:34:24 +0100
> > > > From: Martin Pieuchot
> > > >
> > > > Running
On 04/03/21(Thu) 10:36, Claudio Jeker wrote:
> On Thu, Mar 04, 2021 at 10:28:50AM +0100, Martin Pieuchot wrote:
> > SINGLE_PTRACE has almost the same semantic as SINGLE_SUSPEND. The
> > difference is that there's no need to wait for other threads to be
> > parked.
> >
> > Diff below changes
> Date: Thu, 4 Mar 2021 10:54:48 +0100
> From: Patrick Wildt
>
> Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark Kettenis:
> > > Date: Thu, 4 Mar 2021 10:34:24 +0100
> > > From: Martin Pieuchot
> > >
> > > Running t/rw/msleep(9) w/o KERNEL_LOCK() implies that a thread can
> > > change
Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark Kettenis:
> > Date: Thu, 4 Mar 2021 10:34:24 +0100
> > From: Martin Pieuchot
> >
> > Running t/rw/msleep(9) w/o KERNEL_LOCK() implies that a thread can
> > change the value of `ps_single' while one of its siblings might be
> > dereferencing
single_thread_clear() manipulates the same data structures as
single_thread_set() and, as such, doesn't need the KERNEL_LOCK().
However cursig() does need some sort of serialization to ensure that
per-process data structures like signals, flags and traced-signum stay
consistent. So the diff
> Date: Thu, 4 Mar 2021 10:34:24 +0100
> From: Martin Pieuchot
>
> Running t/rw/msleep(9) w/o KERNEL_LOCK() implies that a thread can
> change the value of `ps_single' while one of its siblings might be
> dereferencing it.
>
> To prevent inconsistencies in the code executed by sibling thread,
On Thu, Mar 04, 2021 at 10:28:50AM +0100, Martin Pieuchot wrote:
> SINGLE_PTRACE has almost the same semantic as SINGLE_SUSPEND. The
> difference is that there's no need to wait for other threads to be
> parked.
>
> Diff below changes single_thread_set() to be explicit when waiting is
>
Running t/rw/msleep(9) w/o KERNEL_LOCK() implies that a thread can
change the value of `ps_single' while one of its siblings might be
dereferencing it.
To prevent inconsistencies in the code executed by sibling thread, the
diff below makes sure `ps_single' is dereferenced only once in various
SINGLE_PTRACE has almost the same semantic as SINGLE_SUSPEND. The
difference is that there's no need to wait for other threads to be
parked.
Diff below changes single_thread_set() to be explicit when waiting is
required. This allows us to get rid of SINGLE_PTRACE now and soon to
use
20 matches
Mail list logo
