tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BPF_MISC+BPF_COP and BPF_COPX
Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:
> Mindaugas Rasiukevicius wrote:
> > Why is it a problem? Given that the byte-code and the functions would
> > come from the same source, some coupling seems natural to me. It is
> > simplistic anyway: some already parsed offsets or values could be
> > passed through the memory store.
>
> You surely have some picture in mind but I can't get it. I'm a bit
> worried that two different environments may look unnatural when married
> together.
OK, but you did not explain why is it a problem i.e. why is it worrying?
> Perhaps, you should right a proposal with some use-cases to support your
> points.
They are simple: consider detecting IP version and calculating the offset
to L4 header. There is no reason to duplicate this work in the byte-code
and the coprocessor. If one of them does it - let's just save it.
> > > Ah, you plan to generalize scratch memory. It's probably fine but
> > > don't generalize too many things because people (me at least) want to
> > > be able to recognize the original bpf and its orignal design.
> >
> > Well, you suggested getter/setter. :)
>
> Yeah, please write a proposal ;-)
>
int bpf_get_memword(const bpf_ctx_t *c, size_t i, uint32_t *val);
int bpf_set_memword(bpf_ctx_t *c, size_t i, uint32_t val);
You prefer something like this?
--
Mindaugas
Home |
Main Index |
Thread Index |
Old Index