New repository for device-tree VPD to Dbus service

[csides-hpe]

Hi folks,

I'm looking for input on a proposal for a new repo to host a VPD (HW ID data) -> Dbus service involved in the Entity-Manager probe/HW discovery processes. The daemon allows Entity-Manager to recognize hardware with Vital Product Data (VPD) discovered via well-known device-tree nodes like 'model' instead of from an I2C-based EEPROM.

This daemon is required for Entity-Manager to be able to recognize HPe hardware, but it relies on well-defined device-tree nodes like 'model' that are not HPe-specific.

I'm currently aware of 4 existing [channel] VPD -> DBus daemons in OBMC:

• FRU_Device (Hosted in Entity-Manager repo, the majority of platforms rely on this. IIRC, some maintainers have expressed they would rather it be hosted in a separate, non-Entity-Manager repo, but that's where it landed) https://github.com/openbmc/entity-manager/tree/master/src

• PECI_PCIe (has own repo) https://github.com/openbmc/peci-pcie

• SMBIOS_MDR (has own repo) https://github.com/openbmc/smbios-mdr

• Openpower-vpd-parser (has own repo) https://github.com/openbmc/openpower-vpd-parser

I'm proposing a new [channel] VPD -> DBus service repo named "MachineContext-DeviceTree-VPD-Parser" or maybe just "DeviceTree-VPD-Parser." I like the idea of having 'vpd' in the name for easier purpose identification like the openpower-vpd-parser repo does.

Here's the current code for the daemon that would be hosted in the proposed repo. The 'MachineContextd' daemon name may be subject to change https://gerrit.openbmc.org/c/openbmc/phosphor-u-boot-env-mgr/+/71512/6/src/machinecontextd.hpp https://gerrit.openbmc.org/c/openbmc/phosphor-u-boot-env-mgr/+/71512/6/src/machinecontextd.cpp

-- any other files were only touched for requested repo-level organizational change reasons): https://gerrit.openbmc.org/c/openbmc/phosphor-u-boot-env-mgr/+/71512

Here's the design doc for the daemon in question, which includes discussion about potential repo hosts for this service that have already been rejected for (Entity-Manager, and Phopshor-u-boot-env-mgr) in the 'Alternatives Considered' section: https://gerrit.openbmc.org/c/openbmc/docs/+/66369

The latest change to the doc includes updates to the 'Alternatives Considered' discussion about which interface and hosting repo should be relied on for this service

Main questions I'm looking to answer:

1. Does the community feel it's reasonable to create a new repo for this Device-Tree VPD -> DBus service? Assuming yes...

2. What should it be named? Would folks be okay with something like 'MachineContext-DeviceTree-VPD-Parser'?

3. How would I start on the process of creating a new repo and pushing it to Gerrit for review and discussion?

---

Design Document https://gerrit.openbmc.org/c/openbmc/docs/+/66369

Naming suggestions: 'MachineContext-DeviceTree-VPD-Parser' 'DeviceTree-VPD-Parser'

Maintainers Christopher.Sides@hpe.com (@CitySides) - https://gerrit.openbmc.org/q/christopher.sides@hpe.com+is:closed Ian.Woloschin@hpe.com (@IWoloschin) - https://gerrit.openbmc.org/q/ian.woloschin@hpe.com+is:closed

[mdmillerii]

https://discord.com/channels/775381525260664832/819741065531359263/1275929514614194176

[amboar]

devicetree-vpd-parser is my suggestion if we're to have a new repo.

[jmbills]

phosphor?

[csides-hpe]

phosphor?

Something I've wondered - what's the usual criteria for a repo to get 'phosphor' prepended to the name?

I'm currently partial towards 'devicetree-vpd-parser' as a name, but 'phosphor-devicetree-vpd-parser' is good too, if that has more of a ring to it.

[williamspatrick]

All of the original repositories had phosphor prepended to ensure we did not have any name collisions with other opensource projects. Later on, other people came on the project and didn't like typing "phosphor" for everything ( :laughing: ) and started dropping it. There is no special "criteria".

[iwoloschin]

I'd vote for no phosphor- prefix unless you're also going to go and make all of the parsers have the phosphor- prefix. I think it'd be confusing for only one parser to have the prefix, especially if it is not the first one someone should look at.