Re: [PATCH v13 00/23] Compile-time stack metadata validation
From: Josh Poimboeuf
Date: Wed Nov 11 2015 - 13:15:17 EST
Do you still have objections to my proposed command-line interface for
As I described below, I still don't think subcommands are a good fit for
stacktool. However, if you strongly disagree, I can change it.
The patch set is now quite mature at v14. Further, it's holding up work
on several other items:
- more frame pointer fixes
- CFI generation and validation
- livepatch consistency model
- DWARF unwinder
So I'm wondering if it would be possible for you to merge stacktool in
time for the next merge window (4.5).
On Mon, Oct 12, 2015 at 09:23:14AM -0500, Josh Poimboeuf wrote:
> On Mon, Oct 12, 2015 at 09:41:11AM +0200, Ingo Molnar wrote:
> > * Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> > > Hi Ingo,
> > >
> > > Do you have any more objections to these patches? Would you be willing
> > > to apply them?
> > So I still don't like the tool namespace you picked: Git-alike generic
> > naming plus subcommands work so much better that I'm not sure why we
> > are even having that discussion:
> Because subcommands are useful in _some_ cases, but they aren't a
> panacea that should be blindly applied everywhere.
> > if you name your tool 'stacktool' and
> > alias everything you have today to under 'stacktool run ...' and add
> > 'stacktool help' as a second, obvious subcommand then you'll have your
> > current syntax and a lot more future flexibility and ability to branch
> > off various functionality a'la Git, perf or kvmtool ...
> Sure, subcommands work great for monolithic framework tools like git,
> perf, yum, docker, etc. But stacktool is not (and never will be) a
> monolithic framework type of tool.
> The suggestion to put 100% of the functionality under 'stacktool run
> [options]' is certainly possible. But 'run' is so broad. What else
> could the tool ever do but 'run'?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/