Redfish EventService Implementation

RAJESWARAN THILLAIGOVINDAN rajeswaran.thillaigovindan at
Sat Feb 1 07:53:47 AEDT 2020


I am going through the bmcweb code for implementing Redfish EventService 
based on the design document This design 
is hooked to the journal based Redfish Event Logging. For life cycle 
events(ResourceAdded, ResourceRemoved, ResourceUpdated),  using D-Bus 
match, bmcweb can create an event log. This requires a JSON dictionary, 
comprising an array of Redfish Resource Name and the D-Bus path. This 
approach works only in case of one to one mapping of Redfish Resource 
Name and the D-Bus path. For propertiesChanged events, if the Redfish 
Resource property is not on the same D-Bus path or the Redfish Resource 
property name is different from the D-Bus property name, then an 
additional JSON dictionary to maintain this information is required. 
With D-Bus match alone in the bmcweb, Redfish EventService can't be 
fully supported. For the Message Registers and the Resource Types that 
are supported, the relevant OpenBMC application must create an event log 
in the journal using either the phosphor::logging::entry or 
sd_journal_send() command.

After realizing that with D-Bus match in the bmcweb alone can't help to 
fully implement EventService, I prefer to avoid using D-Bus match in 
bmcweb. Instead, I prefer to modify the OpenBMC application that 
generated the event to create an event log in the journal. Do you see 
any advantage of using combination of D-Bus match in the bmcweb wherever 
it is possible and changes to OpenBMC application in other cases to 
create an event log ?

Your views are highly appreciated.


More information about the openbmc mailing list