On Tue, Mar 29, 2016 at 12:27 AM, Taylor R Campbell
wrote:
>Date: Mon, 28 Mar 2016 16:07:19 +0900
>From: Ryota Ozaki
>
>On Fri, Mar 25, 2016 at 11:40 PM, Taylor R Campbell
> wrote:
Date: Mon, 28 Mar 2016 16:07:19 +0900
From: Ryota Ozaki
On Fri, Mar 25, 2016 at 11:40 PM, Taylor R Campbell
wrote:
> No need for the _PSZ variants here: the bridge list is used only under
> an exclusive lock.
>
On Fri, Mar 25, 2016 at 11:40 PM, Taylor R Campbell
wrote:
>Date: Wed, 23 Mar 2016 20:03:54 +0900
>From: Ryota Ozaki
>
>...not so much soon though, I prepared patches:
>
Date: Wed, 23 Mar 2016 20:03:54 +0900
From: Ryota Ozaki
...not so much soon though, I prepared patches:
http://www.netbsd.org/~ozaki-r/bridge-psz-list.diff
http://www.netbsd.org/~ozaki-r/bridge-default-mpsafe.diff
The first one introduces membar to
>
>>
>> Thanks to introducing softint-based if_input,
>>we can simplify bridge(4).
>>
>> Awesome! I love patches that have loads more -'s than +'s, and
>> simplify locking schemes, and remove sketchy cpu_intr_p conditionals,
>> and things like that.
>&
On 02/16/16 14:26, David Brownlee wrote:
> a) Single interface machine running xen which needs the xen VMs on an
> internal network with dhcp and VPN/NAT on the external interface (this
> becomes quickly brain twisting and the solution is to plug in an
> additional ethernet card, just to act as
On 15 February 2016 at 04:01, Ryota Ozaki wrote:
> On Sat, Feb 13, 2016 at 7:19 AM, Mouse wrote:
>> Sounds to me as though the most sensible way to model that would be to
>> give the address to the bridge interface itself.
>>
>> I don't think I've
On Sat, Feb 13, 2016 at 7:19 AM, Mouse wrote:
>> tap(4) is a direct interface between userland and the network.
>
> Well, where "the network" refers to the Ethernet stack and higher
> layers within the kernel, not to any real networking medium.
>
>> vether(4) would not
On Fri 12 Feb 2016 at 10:17:31 -0800, John Nemeth wrote:
> tap(4) is a direct interface between userland and the network.
> vether(4) would not be (although you could use BPF, etc.). It
> would be an ethernet device that represents the host. If you know
> how to configure Cisco devices,
>> tap(4) is a direct interface between userland and the network.
>> vether(4) would not be (although you could use BPF, etc.). [...]
> As someone who tinkers with virtual machine emulators (PDP-10, PDP-11
> etc) I like tap(4) very much, [...]. It would be REALLY inconvenient
> if suddenly
On Fri 12 Feb 2016 at 17:19:59 -0500, Mouse wrote:
> Indeed,
> I would say that bridge should not, conceptually, be a network
> interface at all; I suspect it was done as a network interface simply
> because that got a lot of infrastructure for free - and, if it works to
> put an address on the
> Linux takes it even further. If you add an interface to a bridge, the
> interface can't be an IP endpoint any more. You have to use the
> bridge for that instead.
I agree that is stupid. I would advocate against doing it if anyone
were to propose it here.
/~\ The ASCII
Date: Fri, 12 Feb 2016 21:21:29 -0500
From: Thor Lancelot Simon
On Fri, Feb 12, 2016 at 10:17:31AM -0800, John Nemeth wrote:
> tap(4) is a direct interface between userland and the network.
Only if you actually hook something up to the userland side.
On 12/02/2016 08:34, Ryota Ozaki wrote:
> On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote:
>>> [J]ust wondering if we are going to see vether(4) anytime soon.
>>
>> How would this vether differ from the existing tap? Presumably I'm
>> just missing something
>
>
2016/02/11 2:36 "Taylor R Campbell" <campbell+netbsd-tech-k...@mumble.net>:
>
>Date: Wed, 10 Feb 2016 18:56:46 +0900
>From: Ryota Ozaki <ozak...@netbsd.org>
>
>Thanks to introducing softint-based if_input,
>we can simplify bridge(4).
>
On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote:
>> [J]ust wondering if we are going to see vether(4) anytime soon.
>
> How would this vether differ from the existing tap? Presumably I'm
> just missing something
dhcpcd didn't work well with bridge(4) and tap(4)
Ryota Ozaki wrote:
>On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote:
>>> [J]ust wondering if we are going to see vether(4) anytime soon.
>>
>> How would this vether differ from the existing tap? Presumably I'm
>> just missing something
>
>dhcpcd didn't work well
On Feb 12, 10:33am, Roy Marples wrote:
} On 12/02/2016 08:34, Ryota Ozaki wrote:
} > On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote:
} >>> [J]ust wondering if we are going to see vether(4) anytime soon.
} >>
} >> How would this vether differ from the existing tap?
> tap(4) is a direct interface between userland and the network.
Well, where "the network" refers to the Ethernet stack and higher
layers within the kernel, not to any real networking medium.
> vether(4) would not be (although you could use BPF, etc.). It would
> be an ethernet device that
On Fri, Feb 12, 2016 at 10:17:31AM -0800, John Nemeth wrote:
> On Feb 12, 10:33am, Roy Marples wrote:
> } On 12/02/2016 08:34, Ryota Ozaki wrote:
> } > On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote:
> } >>> [J]ust wondering if we are going to see vether(4) anytime soon.
Date: Wed, 10 Feb 2016 18:56:46 +0900
From: Ryota Ozaki <ozak...@netbsd.org>
Thanks to introducing softint-based if_input,
we can simplify bridge(4).
Awesome! I love patches that have loads more -'s than +'s, and
simplify locking schemes, and remove sketchy cpu_intr_p condit
On Feb 10, 6:56pm, Ryota Ozaki wrote:
}
} Thanks to introducing softint-based if_input,
} we can simplify bridge(4).
}
} - Remove spin mutexes
} - They were needed because some code of bridge could run in
} hardware interrupt context
} - We now need only an adaptive mutex for each
> [J]ust wondering if we are going to see vether(4) anytime soon.
How would this vether differ from the existing tap? Presumably I'm
just missing something
> This would simplify the administration and possibly the code of
> bridge(4) in that bridge(4) would become strictly transit and not
>
Hi,
Thanks to introducing softint-based if_input,
we can simplify bridge(4).
- Remove spin mutexes
- They were needed because some code of bridge could run in
hardware interrupt context
- We now need only an adaptive mutex for each shared object
(a member list and a forwarding table
24 matches
Mail list logo