Question on States monitoring

[Andres Oportus]

Thanks Andrew, yeah I see the design philosophy of not exposing low level
stuff like GPIOs unless they mean something more high level (hence the
"State" reference) that could be exposed/monitored/changed/etc.  I'm just
checking to see if we have anything already being thought of or implemented
as to not come up with a custom solution.  The problem is managing "States"
at least initially backed by GPIOs, and it does not have to be on the DBUS
although from what I've seen for instance on IPMI we use DBUS extensively
for things that get exported.

On Mon, May 14, 2018 at 4:16 PM Andrew Jeffery <andrew at aj.id.au> wrote:

> Hi Andres,
>
> On Tue, 15 May 2018, at 01:16, Andres Oportus wrote:
> > Are there any ongoing efforts on expanding States (say provided by GPIOs)
> > monitoring/management?  I see that phosphor-state-manager has
> > Chassis/Host/BMC states that are placed onto DBUS but not a more generic
> > mechanism.  On the GPIO specific side, I see that phosphor-gpio-monitor
> > allows for interrupt driven GPIO monitoring (seemly only used under a
> > gpio-keys driver with /dev/input for Power's checkstop monitoring?), but
> no
> > generic GPIO setting/getting for those not allowing interrupt type
> > monitoring (say output GPIOs).
>
> It's not clear to me what you're looking for here. Are you hoping for
> something to expose the GPIOs on DBus? I don't think we have anything like
> that, which is more of a design philosophy thing (we should probably
> provide a higher-level capability on DBus, not just directly expose GPIOs).
>
> Alternatively if you're looking to handle GPIOs from your application, I
> would recommend libgpiod:
>
> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
>
> Cheers,
>
> Andrew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180514/b5df3e2d/attachment-0001.html>