Look, if you're going to appeal to core to approve changes for
committing then don't bother posting them to tech-net or any other list
because it is quite clear that you are not interested in feedback, only
people to rubber-stamp your ideas.
All of which to say is that I'm sorry I bothered replyin
On Thu, Aug 29, 2013, at 05:27 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
> > Mindaugas Rasiukevicius wrote:
> > > Hi,
> > >
> > > OK, to summarise what has been discussed:
> > >
> > > - Problem
> > >
> > > There is a need to perform more complex operations from the BPF program.
> > >
Darren Reed wrote:
> Mindaugas Rasiukevicius wrote:
> > Hi,
> >
> > OK, to summarise what has been discussed:
> >
> > - Problem
> >
> > There is a need to perform more complex operations from the BPF program.
> > Currently, there is no (practical) way to do that from the byte-code.
> > Such functi
In article <521f4522.5070...@netbsd.org>,
Darren Reed wrote:
>
>The current implementation of BPF makes it very hard to expand
>the instruction set without impinging on the ability to make
>future changes due to the way in which instructions are codified
>into 32bits. Whilst the method of support
Mindaugas Rasiukevicius wrote:
Hi,
OK, to summarise what has been discussed:
- Problem
There is a need to perform more complex operations from the BPF program.
Currently, there is no (practical) way to do that from the byte-code.
Such functionality is useful for the packet filters or other com
Hi,
OK, to summarise what has been discussed:
- Problem
There is a need to perform more complex operations from the BPF program.
Currently, there is no (practical) way to do that from the byte-code.
Such functionality is useful for the packet filters or other components,
which could integrate wi
