vijaykhemka at fb.com
Wed Feb 13 08:33:50 AEDT 2019
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
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:
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
> 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