On 21/09/17 20:44, Alexei Starovoitov wrote:
> On Thu, Sep 21, 2017 at 09:29:33PM +0200, Daniel Borkmann wrote:
>> More intuitive, but agree on the from_be/le. Maybe we should
>> just drop the "to_" prefix altogether, and leave the rest as is since
>> it's not surrounded by braces, it's also not a cast but rather an op.
That works for me.
> 'be16 r4' is ambiguous regarding upper bits.
>
> what about my earlier suggestion:
> r4 = (be16) (u16) r4
> r4 = (le64) (u64) r4
>
> It will be pretty clear what instruction is doing (that upper bits become
> zero).
Trouble with that is that's very *not* what C will do with those casts
and it doesn't really capture the bidirectional/symmetry thing. The
closest I could see with that is something like `r4 = (be16/u16) r4`,
but that's quite an ugly mongrel.
I think Daniel's idea of `be16`, `le32` etc one-arg opcodes is the
cleanest and clearest. Should it be
r4 = be16 r4
or just
be16 r4
? Personally I incline towards the latter, but admit it doesn't really
match the syntax of other opcodes.
To shed a few more bikes, I did also wonder about the BPF_NEG opcode,
which (if I'm reading the code correctly) currently renders as
r4 = neg r4 0
(u32) r4 = neg (u32) r4 0
That printing of the insn->imm, while harmless, is needless and
potentially confusing. Should we get rid of it?
