Opinions on CLI tools.

[Brad Bishop]

If there is value add in these tools, lets get those enhancements in the
associated upstream projects.  I agree with the segmentation and mind-share
kool-aid.

That said, the beauty of Yocto is layers, and if someone felt strongly about it,
this could be added as-is to a meta-<machine> or meta-<company> layer.  Then
the segmentation and mindshare loss would at least be confined to that particular
layer.

-brad


> On Oct 31, 2016, at 11:00 AM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> 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
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc