sandbox: extract PrintProgram() into a separate DumpBPF class

sandbox: extract PrintProgram() into a separate DumpBPF class

Removes some dependencies from codegen.cc as it now only deals with
emitting programs, not with disassembling them too.

BUG=414363
Committed: https://crrev.com/a41c404b1c7ff173dcc51b4bf3b9ab4830af78db
Cr-Commit-Position: refs/heads/master@{#302323}

[mdempsky, 2014-10-31 19:15:37]

mdempsky@chromium.org changed reviewers:
+ jln@chromium.org

[mdempsky, 2014-10-31 19:15:38]

Quick refactoring; will make my followup where I rewrite CodeGen a bit simpler.

[mdempsky, 2014-10-31 19:25:35]

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
File sandbox/linux/bpf_dsl/dump_bpf.h (right):

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
sandbox/linux/bpf_dsl/dump_bpf.h:5: #include
"sandbox/linux/seccomp-bpf/codegen.h"
Aside: I'm kind of disliking that I need to pull in codegen.h in several places
just for the CodeGen::Program typedef (esp in cases like this where we don't
otherwise need CodeGen at all), so I'm considering moving it into a separate
program.h or even just using std::vector<sock_filter>.  But then it doesn't
affect a whole lot of code either...

Let me know your thoughts.

[jln (very slow on Chromium), 2014-10-31 19:30:30]

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
File sandbox/linux/bpf_dsl/dump_bpf.cc (right):

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
sandbox/linux/bpf_dsl/dump_bpf.cc:1: // Copyright (c) 2012 The Chromium Authors.
All rights reserved.
Remove (c) and change to 2014

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
File sandbox/linux/bpf_dsl/dump_bpf.h (right):

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
sandbox/linux/bpf_dsl/dump_bpf.h:1: // Copyright (c) 2012 The Chromium Authors.
All rights reserved.
Remove (c), change to 2014

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
sandbox/linux/bpf_dsl/dump_bpf.h:5: #include
"sandbox/linux/seccomp-bpf/codegen.h"
On 2014/10/31 19:25:35, mdempsky wrote:
> Aside: I'm kind of disliking that I need to pull in codegen.h in several
places
> just for the CodeGen::Program typedef (esp in cases like this where we don't
> otherwise need CodeGen at all), so I'm considering moving it into a separate
> program.h or even just using std::vector<sock_filter>.  But then it doesn't
> affect a whole lot of code either...
> 
> Let me know your thoughts.

Yeah, that seems like a good idea.
How about replacing dump_bpf.h with program.h though?

I could see program.h growing, for things like serializing / deserializing
compiled programs on disk (which is a big word since we'd probably write them
as-is :).

[mdempsky, 2014-10-31 19:37:34]

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
File sandbox/linux/bpf_dsl/dump_bpf.cc (right):

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
sandbox/linux/bpf_dsl/dump_bpf.cc:1: // Copyright (c) 2012 The Chromium Authors.
All rights reserved.
On 2014/10/31 19:30:29, jln wrote:
> Remove (c) and change to 2014

Done.

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
File sandbox/linux/bpf_dsl/dump_bpf.h (right):

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
sandbox/linux/bpf_dsl/dump_bpf.h:1: // Copyright (c) 2012 The Chromium Authors.
All rights reserved.
On 2014/10/31 19:30:30, jln wrote:
> Remove (c), change to 2014

Done.

https://codereview.chromium.org/694013002/diff/1/sandbox/linux/bpf_dsl/dump_b...
sandbox/linux/bpf_dsl/dump_bpf.h:5: #include
"sandbox/linux/seccomp-bpf/codegen.h"
On 2014/10/31 19:30:30, jln wrote:
> On 2014/10/31 19:25:35, mdempsky wrote:
> > Aside: I'm kind of disliking that I need to pull in codegen.h in several
> places
> > just for the CodeGen::Program typedef (esp in cases like this where we don't
> > otherwise need CodeGen at all), so I'm considering moving it into a separate
> > program.h or even just using std::vector<sock_filter>.  But then it doesn't
> > affect a whole lot of code either...
> > 
> > Let me know your thoughts.
> 
> Yeah, that seems like a good idea.

Cool, I'll send a followup CL for that.

> How about replacing dump_bpf.h with program.h though?
> 
> I could see program.h growing, for things like serializing / deserializing
> compiled programs on disk (which is a big word since we'd probably write them
> as-is :).

My feeling is DumpBPF is going to grow a bit and it'll make sense to stay
logically distinct from the rest of program.h, but maybe not.  I'll play around
with it and see.

[mdempsky, 2014-10-31 19:37:38]

The CQ bit was checked by mdempsky@chromium.org

[commit-bot: I haz the power, 2014-10-31 19:39:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/694013002/20001

[commit-bot: I haz the power, 2014-10-31 19:39:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-10-31 19:39:17]

No LGTM from a valid reviewer yet. Only full committers are accepted.
Even if an LGTM may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[jln (very slow on Chromium), 2014-10-31 19:40:30]

lgtm

[jln (very slow on Chromium), 2014-10-31 19:40:33]

The CQ bit was checked by jln@chromium.org

[commit-bot: I haz the power, 2014-10-31 19:41:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/694013002/20001

[commit-bot: I haz the power, 2014-10-31 20:50:36]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2014-10-31 20:51:10]

Patchset 2 (id:??) landed as
https://crrev.com/a41c404b1c7ff173dcc51b4bf3b9ab4830af78db
Cr-Commit-Position: refs/heads/master@{#302323}