search

openbmc / technical-oversight-forum

6 stars 1 forks source link

OpenBMC should continue to move toward more consolidated repo and branching models #21

Open edtanous opened 1 year ago

edtanous commented 1 year ago

This TOF request is looking for direction on the proposal below, which proposes to merge a number of the sub-repositories into a single structure, to allow a number of positive attributes. This was discussed on the mailing list on a couple of different occasions [1][2] and garnered conflicting support. Obviously, not all the technical hurdles have been sorted out, but it's clear there are potential paths to getting them sorted out, but will be non-trivial amounts of effort. This bug is requesting an indication of support or non-support for the overall direction laid out in [1], to be able to prioritize the remaining items appropriately, and if the overall direction is a non-starter, to avoid wasting effort.

[1] https://lore.kernel.org/openbmc/CAH2-KxAJS_U8=meCxp8ue7n0bmnzeRpyZOPZpy0h1cFEbbz-HA@mail.gmail.com/ [2] https://lore.kernel.org/openbmc/77004044-4ea7-8086-eab9-ac3c6d4bd634@linux.intel.com/T/#m80af9edd4b92197ee0485b167fa2515e9e5876a9

bradbishop commented 1 year ago

I like to think about structuring the OpenBMC C++ userspace like systemd. We have a lot in common. Systemd provides many microservices and shared libraries, along with supporting configuration such as unit files and dbus policy - all in a single repository that you can configure and build with meson.

Thinking about it from this point of view has a couple immediate benefits IMO:

1 - build configuration is done with meson instead of bitbake/yocto. This could be a pro or a con, depending on whether or not you think meson is easier than bitbake/yocto. I think most humans would choose meson.

2 - the barriers to sharing code between applications are significantly reduced.

3 - the bitbake metadata is greatly simplified. Only a single recipe is required. No need to implement and maintain distro or machine features across dozens of recipes. All the configuration possibilities are defined in the main "openbmc" recipe as packageconfigs and machine layers simply become a single bbappend that selects all the appropriate meson options (as packageconfigs).

As a result of this movement of the configuration logic from yocto/bitbake to meson, interesting possibilities emerge such as:

bradbishop commented 1 year ago

I'm going to go ahead with a thumbs up with the caveat that we only consolidate the c++ code down to a single repo...at least for now.