Host-side tools

[Vijay Khemka]

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.
    
    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.