Host-side tools

[Patrick Venture]

On Tue, Feb 12, 2019 at 1:33 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>
> On 2/11/19, 3:08 PM, "openbmc on behalf of Patrick Venture" <openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of venture at google.com> wrote:
>
>     On Mon, Feb 11, 2019 at 2:58 PM Patrick Venture <venture at google.com> wrote:
>     >
>     > On Mon, Feb 11, 2019 at 11:49 AM William Kennington <wak at google.com> wrote:
>     > >
>     > > As long as it's possible to build the host side tooling without
>     > > building any of the BMC side tooling and vice versa it sounds fine to
>     > > me.
>     >
>     > I've been doing a lot of host-side development lately and I was
>     > interested to know what the end result would be.  If someone ran the
>     > configuration just to use the tool, they might run into issues.  I've
>     > avoided using BMC-side libraries where possible to avoid host-side
>     > tool poisoning.
>     >
>     > >
>     > > On Mon, Feb 11, 2019 at 10:51 AM Brad Bishop
>     > > <bradleyb at fuzziesquirrel.com> wrote:
>     > > >
>     > > > On Mon, Feb 11, 2019 at 08:03:17AM -0800, Patrick Venture wrote:
>     > > > >Brad,
>     > > > >
>     > > > >It's my understanding that host-side tools that cooperate with bmc-side
>     > > > >tools should be in the same repo,
>     > > >
>     > > > Is this something I said at some point?  Where is this coming from?
>     >
>     > I don't have the exact email, and it might have been very very stale
>     > information.  But I'm glad to clear this up! :D
>     >
>     > > >
>     > > > >hence why the host-side blobs stuff is in phosphor-ipmi-flash.
>     > > > >However, if I add any dependencies to the configuration for the
>     > > > >BMC-side, those get in the way of configuring for the host-side.  Would
>     > > > >it not make sense to sometimes have it split?  And if so, I would like
>     > > > >to propose creating two repos, a blobs library host-side, and a flash
>     > > > >tool host-side repo, so those can be neatly split and not have anything
>     > > > >in their configuration file that's really bmc-side specific, like
>     > > > >ipmid, or phosphor-dbus-interface, or something.
>     > > >
>     > > > I can make a repo if you would like.  Just let me know what you would
>     > > > like it called.
>     >
>     > Thanks.  I'm working on an IPMI blob toolset, such that there is a
>     > library that provides host-side blob tooling, and then the flash host
>     > toolset can link against that library and be used on the host.
>     >
>     > So that's my goal.  To get there I was thinking,
>     > phosphor-ipmi-blobs-tool (or ipmi-blobs-lib) and
>     > phosphor-ipmi-flash-tool for that side.  The argument against
>     > ipmi-blobs-lib is that there may end up being some basic tool there
>     > tool and not just the library -- do you have any preference in this
>     > case?
>
>     Reviewing my goals further, the idea of having an ipmi-blobs-lib or
>     ipmi-blobslib repo would be helpful.  I could do all the host-side
>     blob tooling there, and have that be a dependency of
>     phosphor-ipmi-flash-tool.  Which leaves me with two repo requests:
>
>     ipmi-blobslib
>     phosphor-ipmi-flash-tool
>
> Can we name as "phosphor-host-tools instead of calling ipmi-blob.
> As we can have similar tools repo for bmc and we can call it as
> phosphor-bmc-tools. All host related tools can be in one single
> repo and bmc tools can be in another single repo.

There's already a repo, iirc for some BMC tools.  And, I don't know
that storing arbitrary host-tools in the same repo is a plan I can
support - unless they're all cpp built the same way, but really at
that point it feels like if someone wanted to build their one tool it
might be more steps?

>
>     You could add the phosphor prefix to the ipmi-blobslib if you wanted
>     for consistency since its' meant to work with and on the phosphor
>     environment.
>
>
>     >
>     > I'm definitely seeking suggestions on this.
>     >
>     > > >
>     > > > That said, I think you can also probably do this in the same repo, if
>     > > > you wanted, by having different build targets - it might not make any
>     > > > sense to try and build both applications with a single invocation of
>     > > > configure - as you point out, they are being "configured" for vastly
>     > > > different runtime environments.
>
>