Opinions on CLI tools.

[Patrick Williams]

I decided we should solicit broader feedback before I merge this commit:
    https://gerrit.openbmc-project.xyz/#/c/900/2

Xo proposed adding a CLI tool, that appears to have been written and
maintained by someone at Google, and effectively is a wrapper around a
number of device driver calls.  Some of the facilities provided by this
tool would also be provided by "upstream" tools like i2c-tools or pdbg.

Last week the IBM team had a small discussion on strategies for CLI
tools.  In our legacy product, developers tended to make many many CLI
tools with little oversight and standards and these tools ended up
slipping into various "bring up", "debug" and "manufacturing" scripts,
effectively becoming "requirements".  For OpenBMC, we had proposed
landing on the other extreme of this, which is to say we should never
have a CLI tool as a wrapper around an existing tool or to replace
existing upstream functionality.  (We did have one small tool we
discussed which was to facilitate easier interaction with the DBus
interfaces, since otherwise would require a few invocations of 'busctl')

One of our (my) concerns about wrappers is that we end up segmenting our
own community from the broader Linux ecosystem.  Having available and
documenting broader tools like 'i2c-tools', 'systemctl', 'journalctl'
gives us larger mind-share with individuals outside OpenBMC that are
already familiar with those tools.

A key example we discussed was:
        obmcutil power-on
    vs
        systemctl start host0-power-on.target

The first is certainly "easier" for those that are totally newcomers.
The second is only slightly more difficult but gives insight into how
our state-management works.  With the second if someone already has
knowledge in systemd, from their own Linux experience, that allows them
to more likely probe into "what else is exposed via systemd targets?"
rather than just expecting everything to be documented with 'obmcutil
--help'.

With this proposed iotools package I think we have 3 options:

1.  Allow it in, as is, in the debugtools image.  Even though it does
replicate / wrap some tools, it does provide new abstractions on others.

2.  Add it to a .bbappend in only the meta-zaius tree.

3.  Patch the makefile (and discuss with upstream) to disable
functionality that is already implemented by other, more widely used,
tools like i2c-tools.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161031/270ea2cb/attachment-0001.sig>