Policy on Tools Posting

[Wilfred Smith]

To what extent Is this an actionable “ruling” vs “thoughts on the matter.” 

While large vendors can easily assign someone to create utilities like these, won’t less well staffed vendors be served by having a collection of utilities to choose from? If nothing else, I would think just having the examples available for their adaptation adds significant value. Should everyone need to write their own utility to send a message to ME?

Isn’t FruDevice a well-adopted interface? IpmbBridge? 

I suppose I’m unclear on the project audience, so please guide me. Are we providing hobbyist parts that a billion-dollar enterprise with person-hours to burn can use to create a production system or a near-complete solution that requires a few days of “roughing in” and customization by a three-person team in East Canberra? Is OpenBMC more minimalist “Alpine Linux” or fully loaded, ready-to-go “Ubuntu”?

What’s the dividing line between “Core OpenBMC” and “stuff you need to find or build yourself” where the OpenBMC community is aware, but hands-off?

Pardon me if there’s a document somewhere that states this, in which case a link would be appreciated.

Is the safest bet for the moment to follow your mini-design doc path and host in Facebook’s public Github as described in your last paragraph?

Again, pardon my ignorance as a latecomer here.

Wilfred

> On Aug 15, 2019, at 5:55 AM, Andrew Geissler <geissonator at gmail.com> wrote:
> 
> On Mon, Aug 12, 2019 at 7:58 PM Wilfred Smith <wilfredsmith at fb.com> wrote:
>> 
>> 
>> 1. Are there guidelines/procedures specific to submitting command line tools and utilities? I have heard that there may be a repository and/or path dedicated to CLI tools.
> 
> The community has definitely tended to limit wrapper tools within
> OpenBMC. We had a discussion a while back that we're open to some but
> the API's to them really need to be thought out and reviewed because
> command line tools become customer API's (i.e. people start writing
> scripts on top of these tools that then become key to the
> manufacturing process or some other critical area).
> 
> Anything that goes into OpenBMC needs to support OpenBMC interfaces.
> For example, I'm not familiar with fruid-util's D-bus service
> xyz.openbmc_project.FruDevice. A "busctl tree
> xyz.openbmc_project.Inventory.Manager | cat" shows the inventory items
> on OpenBMC.
> 
> One issue we have within OpenBMC is there may be different
> implementations of the D-bus API's for a given area. For example,
> Inventory has different implementations so I'm not sure which repo
> would best fit your tool. That type of issue leads me to wonder if we
> should put the tools with the interface definitions in
> openbmc/phosphor-dbus-interfaces? Or maybe a separate phosphor-tools
> repo would be more logical for these.
> 
> Either way, I think command line tools should each get their own
> mini-design doc
> (https://github.com/openbmc/docs/blob/master/designs/design-template.md)
> with requirements and interfaces clearly defined for review by the
> community. If we can find a generic tool that multiple people find
> useful, we can then find a place to put it. Otherwise, you could host
> your tools outside of openbmc/ github and just pull them into recipes
> from within your meta-facebook layer.
> 
>> Thanks in advance,
>> 
>> Wilfred