Host-side tools

Patrick Venture venture at google.com
Wed Feb 13 04:11:59 AEDT 2019


On Mon, Feb 11, 2019 at 3:07 PM Patrick Venture <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
>
> 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.

Brad + William,

I was thinking about this more -- w.r.t the configure script, i could
put the blobs host-side library portion into the phosphor-ipmi-blobs
repo and have it build and install a library.  And could use enable or
disable to only check for things like phosphor-logging if it's being
built for the BMC.  I'm just not sure what the idiomatic approach is
for that -- or maybe a build variable, like "build-host-library=yes"
or something.

Patrick

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


More information about the openbmc mailing list