<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><span style="font-family: monospace;">Hi OpenBMCers,</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">I've been working on some different areas of OpenBMC recently, and have</span><br style="font-family: monospace;"><span style="font-family: monospace;">noticed that there seems to be increasing fragmentation between various</span><br style="font-family: monospace;"><span style="font-family: monospace;">platform and infrastructure code.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">One of the main impacts I've seen as a consequence is that it's</span><br style="font-family: monospace;"><span style="font-family: monospace;">becoming incredibly difficult for new adopters and contributors to do a</span><br style="font-family: monospace;"><span style="font-family: monospace;">platform port.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">I definitely understand that contributing companies have their own</span><br style="font-family: monospace;"><span style="font-family: monospace;">product timelines and priorities, which doesn't always correlate with</span><br style="font-family: monospace;"><span style="font-family: monospace;">OpenBMC development directions. We need to allow that for the project</span><br style="font-family: monospace;"><span style="font-family: monospace;">as a whole to be viable. But I still think there's scope to both</span><br style="font-family: monospace;"><span style="font-family: monospace;">improve the coherence of the OpenBMC work, while also allowing variance</span><br style="font-family: monospace;"><span style="font-family: monospace;">where justified, in a way that makes sense.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">To pick a couple of examples and consequences:</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;"> - there are a lot of out-of-tree patches around. While this isn't</span><br style="font-family: monospace;"><span style="font-family: monospace;">necessarily a problem in its own right, some of these are fundamental</span><br style="font-family: monospace;"><span style="font-family: monospace;">to make the upstream platforms work. For anyone adopting those</span><br style="font-family: monospace;"><span style="font-family: monospace;">platforms as a reference, it means that they have a non-functional</span><br style="font-family: monospace;"><span style="font-family: monospace;">platform, or have to use the non-upstream repos.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;"> - there's increasing amounts of code that require or implement non-</span><br style="font-family: monospace;"><span style="font-family: monospace;">standard behaviour; For example, dbus-sensors exposes and consumes dbus</span><br style="font-family: monospace;"><span style="font-family: monospace;">interfaces that are not described by phosphor-dbus-interfaces. This</span><br style="font-family: monospace;"><span style="font-family: monospace;">means that the divergence is then needed in other projects too. If</span><br style="font-family: monospace;"><span style="font-family: monospace;">those standards don't suit actual requirements, then we should look at</span><br style="font-family: monospace;"><span style="font-family: monospace;">updating them.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">Just to be 100% clear though, I am definitely not singling-out the</span><br style="font-family: monospace;"><span style="font-family: monospace;">meta-intel platform support; it's just what I've been experimenting</span><br style="font-family: monospace;"><span style="font-family: monospace;">with recently. Intel have done great upstream work on OpenBMC, and</span><br style="font-family: monospace;"><span style="font-family: monospace;">these issues are only apparent because of the work already done. It</span><br style="font-family: monospace;"><span style="font-family: monospace;">just feels like we're 90% there, and the rest would make the world of</span><br style="font-family: monospace;"><span style="font-family: monospace;">difference for new users.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">So, a few things that I think may help the situation:</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;"> - Adherence to standards. Being a little more strict about what</span><br style="font-family: monospace;"><span style="font-family: monospace;">comprises an OpenBMC implementation will go a long way to prevent</span><br style="font-family: monospace;"><span style="font-family: monospace;">future incompatibilities, and means that all of our interface</span><br style="font-family: monospace;"><span style="font-family: monospace;">implementations automatically document their expected behaviour</span><br style="font-family: monospace;"><span style="font-family: monospace;">(because that's in the standard).</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;"> - Identification of a set of reference platforms. If we can point</span><br style="font-family: monospace;"><span style="font-family: monospace;">adopters to a platform that provides a recommended (and somewhat</span><br style="font-family: monospace;"><span style="font-family: monospace;">"supported") way of doing things, that would prevent a lot of confusion</span><br style="font-family: monospace;"><span style="font-family: monospace;">around different implementations, and how to best work with the options</span><br style="font-family: monospace;"><span style="font-family: monospace;">available</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;"> - Documentation of interactions between components. There's some great</span><br style="font-family: monospace;"><span style="font-family: monospace;">documentation on how our components work, but not a whole lot on how</span><br style="font-family: monospace;"><span style="font-family: monospace;">they fit together. Without this, it means a lot of jumping around</span><br style="font-family: monospace;"><span style="font-family: monospace;">between repos, trying to find the "other side" of each interface.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;"> - Keep pushing on upstream. Sometimes this can delay things, but I</span><br style="font-family: monospace;"><span style="font-family: monospace;">really think that's almost always false economy; the out-of-tree</span><br style="font-family: monospace;"><span style="font-family: monospace;">patches will have to be addressed at some point, and that job just gets</span><br style="font-family: monospace;"><span style="font-family: monospace;">more involved as time passes. Even engaging other community members to</span><br style="font-family: monospace;"><span style="font-family: monospace;">help out would be great.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">Finally, I don't mean this to sound like a bunch of complaints - I'm</span><br style="font-family: monospace;"><span style="font-family: monospace;">keen to put in a bunch of time to address things. I'd just like to</span><br style="font-family: monospace;"><span style="font-family: monospace;">start some discussion on how best to do that, before I do so.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">So - any thoughts on how we can improve this? Comments / disagreements</span><br style="font-family: monospace;"><span style="font-family: monospace;">/ questions always welcome.</span><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">Cheers,</span><br style="font-family: monospace;"><br style="font-family: monospace;"><br style="font-family: monospace;"><span style="font-family: monospace;">Jeremy</span></body></html>