[bluez/bluez] 514701: Refactor uid_state handling

["github-actions[bot]" <noreply@github.com>]

  Branch: refs/heads/974231
  Home:   https://github.com/bluez/bluez
  Commit: 514701a0867a9c478d6f50e203fb16f14b46580e
      https://github.com/bluez/bluez/commit/514701a0867a9c478d6f50e203fb16f14b46580e
  Author: Andrew Sayers <kernel.org@pileofstuff.org>
  Date:   2025-06-20 (Fri, 20 Jun 2025)

  Changed paths:
    M obexd/client/driver.c
    M obexd/client/driver.h
    M obexd/client/pbap.c
    M obexd/plugins/bluetooth.c
    M obexd/src/logind.c
    M obexd/src/logind.h
    M obexd/src/main.c
    M obexd/src/transport.c
    M obexd/src/transport.h

  Log Message:
  -----------
  Refactor uid_state handling

We talked recently about refactoring logind.{c,h} to fit more neatly
into the program's wider architecture.  This patch sketches out a
possible approach.  It compiles, but has not been tested beyond that.
If I'm on the right track, I'll come back with a proper solution.

The old API provided callbacks on high-level "init" and "exit" events.
That made sense for the limited case it was used for, but seems
unlikely to scale if this starts picking up more use cases.  So the
RFC API just provides a single event that passes a `logind_cb_context`
struct to callbacks, and provides `LOGIND_USER_IS_ACTIVE(ctxt)` to
replicate the old behaviour.

The old API invited individual transports/drivers to use it directly,
which again made sense for version 1, but bypassed `transport.h` and
`driver.h`.  The RFC API registers callbacks with `driver.h` and
`transport.h` in a more normal way, and they pass `logind_cb_context`
straight through to the callbacks.  That means we won't need to do
much refactoring if the struct changes some day, but also means
individual transports/drivers need to know about `logind.h`.
The alternative would look something like this:



To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications