Opinions on CLI tools.

[Xo Wang]

Hi Patrick, Brad:

Based on your criteria, I think iotools would fall into the category
of a narrow-mindshare tool when viewed from the broader project
perspective.

We'll keep the iotools image inclusion internal to our layer, since
the primary benefit is Google developer familiarity and ease of
porting our collection of traditionally host-side scripts that depend
on it.

cheers
xo


On Tue, Nov 1, 2016 at 6:30 AM, Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
> 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
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc