Darren Reed wrote:
> > What is "vendor private"? It does not really matter how you label it.
>
> Yes, it does.
>
> By defining an instruction to be "something" there is an expectation that
> it will be used for that "something."
Your "something" is rather vague. BPF_COP is used by NetBSD, sta
Darren Reed wrote:
> >> It seems that we really wind up needing a registry of co-processor
> >> function indexes... which begin to seem like new instructions in some
> >> sense. Perhaps the difference is that they are better defined, and more
> >> dynamic.
>
> If libpcap/bpf goes down the path of
On Wed, 20 May 2015 08:59:22 +1000
Darren Reed wrote:
> > It would be good to have some general purpose coprocessor (for
> > walking IPv6 header chain and other operations), but that would
> > probably be difficult to agree and standardise amongst the
> > vendors.
>
> Which speaks to BPF needi
On 18/05/2015 9:31 AM, Mindaugas Rasiukevicius wrote:
Michael Richardson wrote:
Mindaugas Rasiukevicius wrote:
> A while ago NetBSD gained support for BPF_COP instruction, see [1]
> for more details. However, now there are use cases of it outside
> the NetBSD kernel, e.g. stand
Michael Richardson wrote:
> Mindaugas Rasiukevicius wrote:
> > A while ago NetBSD gained support for BPF_COP instruction, see [1]
> > for more details. However, now there are use cases of it outside
> > the NetBSD kernel, e.g. standalone NPF packet filter running as a
> > program
