Reducing fragmentation in OpenBMC

[Vernon Mauery]

On 20-May-2020 10:25 AM, 郁雷 wrote:
>On Tue, May 19, 2020 at 8:50 PM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>>
>> On Tue, 2020-05-19 at 10:25 +0800, 郁雷 wrote:
>> > On Tue, May 19, 2020 at 8:53 AM Andrew Geissler <
>> > geissonator at gmail.com> wrote:
>> >
>> > > I know phosphor-dbus-interfaces has always been a bit onerous. I do
>> > > feel like
>> > > we get some good stuff in the reviews though. It also ensures we
>> > > have
>> > > documentation  of our interfaces. The cross-repo dependencies we
>> > > get are a bit frustrating (i.e. need to get interface merged and
>> > > bubbled into
>> > > openbmc before you can implement). There’s also no versioning
>> > > concept so
>> > > if an interface needs to be changed, it’s a huge pain. Ideas on how
>> > > we could
>> > > make this easier but keep the benefits? Or people that don’t use it
>> > > and just
>> > > define their own interfaces, any improvements we could make to get
>> > > you to use it?
>> > >
>> >
>> > This usually involves the repo CI.
>> > If we could implement "Cross-repo dependencies", making the Jenkins
>> > job able to pick the "dependent" revision of phosphor-dbus-interfaces
>> > (or sdbusplus, or else), and build a docker container with the
>> > dependencies to run the repo CI, the issue could be resolved.
>>
>> This would be a nice feature to have in our CI when cross repo
>> dependencies come up.  But I don't think  having that would give us
>> free license to add cross repo dependencies everywhere though - I would
>> like to see us come up with a system that avoids the need for cross-
>> repo dependencies in the first place.
>
>As Andrew indicates, phosphor-dbus-interfaces is the major cross repo
>dependency already.

Would it be possible to have the D-Bus interfaces in the repo that 
provides it? If the yaml->c++ generator is used (sdbusplus) then it 
could be run IN that repo as part of the build. If the yaml->c++ 
generator is not used (sdbusplus-asio) then maybe we could figure out 
some auto-generated unit tests that validate that the provider actually 
does serve the interface as it is defined in the yaml.

This would make it harder to find where the interface is, but it would 
reduce the dependency problem. Also, it would make it difficult for 
multiple things that provide the same interface.

Just throwing ideas out there.

--Vernon