x/net/bpf: implement interface fmt.Stringer on BPF instructions

[breml]

What version of Go are you using (go version)?

go version go1.7.4 linux/amd64

What operating system and processor architecture are you using (go env)?

linux, amd64

What did you do?

I would like to print bpf.Instructions in the assembler notation defined in https://www.kernel.org/doc/Documentation/networking/filter.txt.

What did you expect to see?

I suggest to implement fmt.Stringer an all types which implement bpf.Instruction.

For example the instructions

[]bpf.Instruction{
	bpf.LoadExtension{Num: bpf.ExtRand},
	bpf.JumpIf{Cond: bpf.JumpGreaterThan, Val: 4294967, SkipTrue: 1},
	bpf.RetConstant{Val: 1024},
	bpf.RetConstant{Val:0},
}

could be printed as

ld #rand
jgt #4294967, 1
ret #1024
ret #0

I have an implementation for the output in assembler notation (without fmt.Stringer): https://github.com/breml/bpfutils/blob/master/string.go#L26-L218 and I offer to provide a CL for the above suggestion, if this change is accepted.

What did you see instead?

Is not implemented.

[titanous]

/cc @danderson @mikioh

[danderson]

This seems fine, and a CL would be welcome as far as I'm concerned (though I don't have direct commit access, @mikioh has the final say there).

The only thing I'm worried about is what to do about RawInstruction. By design, RawInstruction is also an Instruction, so that programmers can specify custom opcodes for forks of the BPF machine. Those instructions might not match a known instruction of the Linux BPF implementation, so... What does String() return for that?

I suppose the simplest option is simply to not implement fmt.Stringer on RawInstruction. Does that seem reasonable to you?

[breml]

It is not my intend to extend the existing bpf.Instruction interface but simply implement the fmt.Stringer interface on the types (like bpf.RetConstant) where it makes sense (respectively where the assembler instruction is defined).
So I fully agree with the suggestion by @danderson to not implement fmt.Stringer on RawInstruction.

[mikioh]

I'll push the submit button once @danderson is happy.

[danderson]

@breml's plan sounds great to me. Is there a CL already? I'll happily review one.

[breml]

@danderson there is not yet a CL. The implementation is straight forward. Currently I am looking for the best way to implement the tests.

One possibility would be to add a go style table driven test which includes for every bpf.Instruction the expected string.
An other possibility would be to use the already existing testdata and validate, that for all instructions in testdata/all_instructions.bpf the respective line in testdata/all_instructions.txt is generated. The downside of this approach is, the instructions in testdata/all_instructions.txt do need some preprocessing (remove all lines with comments, remove empty lines a and most importantly resolve the jump labels to the correct relativ jump distance).

@danderson what do you suggest?

[breml]

@danderson Just uploaded a CL, which uses option 1 for the tests (see my previous comment).

[gopherbot]

CL https://golang.org/cl/35171 mentions this issue.