Hi Patrick,

Thanks for the response. Sure. I will open an issue in TOF for requesting a
new repository.

Thanks,
Kumar.

On Sat, Jan 15, 2022 at 12:22 AM Patrick Williams <patrick@stwcx.xyz> wrote:

> On Wed, Jan 05, 2022 at 07:53:18PM +0530, Kumar Thangavel wrote:
> > On Wed, Jan 5, 2022 at 1:20 AM Ed Tanous <ed@tanous.net> wrote:
> >
> > > On Mon, Jan 3, 2022 at 11:55 PM Kumar Thangavel
> > > <kumarthangavel.hcl@gmail.com> wrote:
> <<clipped>>
>
> We are initially supporting the non-open BIC implementation that we had on
> Yosemite v1,2, and 3, but we have recently started a fully open source
> implementation of the BIC side of this:
>
>     https://github.com/facebook/OpenBIC
>
> We'd certainly be interested in collaborating if anyone else is interested
> in
> designing a system using a uC like this.  Basically the BIC acts as an IO
> expander for the BMC so that we can manage multiple hosts and/or
> accelerator
> cards.
>
> At a high-level this is similar to the PLDM subsystem.  We have some IPMB
> events
> that the BIC push to the BMC and we already have those handled in the IPMI
> handlers, but there are other parts of the design where the BMC initiates
> activity.
>
> We could certainly spread the implementation out into various repositories,
> like dbus-sensors and phosphor-bmc-code-mgmt, but I suspect there are
> going to
> be challenges in a bug-free implementation in that regard.  There are cases
> where asking the BIC to do one activity, such as update itself, takes
> offline
> some other pieces of functionality, like sensors, and so there does need
> to be
> some state-awareness.  It seems less error prone to put all the various
> DBus
> objects related to the BIC into one daemon/repository in the same manner as
> PLDM is doing.
>
>
> Kumar, in order to get closure on this, I think you should open an issue to
> technical-oversight-forum requesting a repository.  Repository oversight is
> one of the primary functions of the TOF.
>
> --
> Patrick Williams
>