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