When the Loader upgrade step was moved prior to platform setup the upgrade status was lost
because the platform-current symlink had not been created yet.
This simple fix places the upgrade status file in the absolute directory instead of
the symlinked directory.
The loader status and the firmware status should probably be separated anyways.
The loader status doesn't belong in the platform-specific data.
Clients register a filesystem path they wish to publish
as a domain socket their handlers are called when
the domain socket is accessed.
Some ONLP data can only be retreived by accessing another process
Which cannot be part of the ONLP layer itself for various reasons.
The ONLP File APIs already support unix domain sockets for all operations
as if they were regular files and certain features are already implemented
using this mechanism (see the examples below).
This module provides a common framework to implement the server side of the
domain socket as well (which is currently up to the platform integrator).
Some examples of how this is used:
- Reporting the switch internal thermal temperature
- This can only be accessed by the code managing the switch.
- In this case the switch management agent exports a domain socket
that reports the temperature when the socket is read and the
thermali implementation uses that domain socket to satisfy
the request for the OID.
- SFP Access through the switch
- Some platforms implement SFP I2C access through a bus connected
to the switch itself.
- Only the agent running the switch can access the SFP eeproms.
- In this case the strategy is for the switch agent to export domain
sockets for each SFP which can be used to read the SFP status/eeprom
etc. The SFPI interface then reads these domain sockets to get the
required information.
Standardizing on this method allows all system ONLP clients to access
all data, even if that data is present only in seperate processes.
