Commit Graph

119 Commits

Author SHA1 Message Date
hayodea c0798d1bdb DevMgr: detachAll only detaches from attachedDeviceRoles
We no longer try to detach from the collection of specs. We
detach from the collection of attachedDeviceRoles. This means
our cleanup sequence no longer tries to clean up things that were
never set up to begin with.
2025-09-28 13:04:07 -04:00
hayodea e45a9ee5d1 DAP.yy: use cmdlineDASpecs; DevMgr: add attachAllUnattachedDevicesFromCmdlineReq
This method wraps around attachAllUnattachedDevicesFromReq and supplies
it with a sh_ptr<> collection of all DASpecs parsed by the DAP parser
from the cmdline.

The initialization sequence now correctly initializes all DAP specs
given on the cmdline again.
2025-09-28 12:52:59 -04:00
hayodea b43ffcb677 DevMgr: attachAllUnattachedDevsFrom: now takes sh_ptr<vector<Spec>>
This method now accepts a sh_ptr<vector<DeviceAttachmentSpec>> to
tell it specifically which specs to attempt to attach.

This enables us to implement different frontends that supply it
with collections of devices from different sources (GUI, cmdline,
previously failed-to-attach/hot-removed devices, etc).

SMO temporarily initializes none of the devices from the cmdline
during this commit as we transition to implementing the cmdline
collection frontend.
2025-09-28 12:39:45 -04:00
hayodea 2c60248127 DevMgr: Rename at/detachAll*Req():
We've renamed these now to better reflect what they do.
* attachAllSenseDevicesFromSpecsReq=>attachAllUnattachedDevicesFromReq
* detachAllSenseDevicesReq=>detachAllAttachedDeviceRoles

This is also the first step in changing
attachAllUnattachedDevicesFrom to accept a sh_ptr<> to a collection
of DeviceAttachmentSpecs. This will enable us to unify the underlying
spec attachment logic and just create several front-ends for attaching
specs from multiple sources.
2025-09-28 12:19:56 -04:00
hayodea 993bf568fc DevMgr: implement removeDeviceAttachmentSpecReq
This reverts all state changes made by newDeviceAttachmentSpecInd.
2025-09-28 11:41:20 -04:00
hayodea 27e707a22d DevMgr:newDevAttSpecInd: take ref & not sh_ptr to DASpec
Because NewDevAttSpecInd should be the function that creates the
persistent sh_ptr state within DevMgr.
2025-09-28 11:14:55 -04:00
hayodea 7ab6e7b2c3 Formatting 2025-09-28 11:05:04 -04:00
hayodea 5b2354bfe0 DevMgr:newDevAttSpecInd: creates Device in frontend
There's no reason why we have to only create the Device at the
end if everything succeeds. The Device isn't the same thing as the
DeviceRole.
2025-09-28 10:57:43 -04:00
hayodea 42ab935da6 Reorder operations 2025-09-28 09:19:09 -04:00
hayodea 572a8612ed DevMgr,Dev: Add Qutexes
Add Qutex locks to both DeviceManager and Device. These will be
properly used in the upcoming patches.
2025-09-28 01:27:32 -04:00
hayodea 51b70b179c DevMgr: call newDevAttSpecInd & not attDevReq in body:initReq
This performs a more complete device initialization and attachment
sequence. We'll do the corresponding teardown in the shutdown
sequence later.

We might probably do it as deviceRoleGoneAwayInd()
2025-09-28 01:15:36 -04:00
hayodea 1a56e2a107 DevMgr: Add DeviceRoles; attachedDevices unrelated to device state now
We've decided to add a separate notion of a DeviceRole to track attached
device roles now. We no longer use the collection of deviceSpecs to
track which roles have been attached. Rather, this list will simply
collate all known deviceAttachment specs which are expected to be
maintained in an attached state.

SMO can periodically scan through these and cross-reference this
collection with the collection of attachedDeviceRoles. Then it can
re-try to attach those which aren't currently attached at any given
moment. This will give resilience against device attachment failures
or device resets/malfunctions, at runtime.
2025-09-28 00:50:05 -04:00
hayodea e6b8d3e85d DevMgr: Move at/detachSenseDevs[FromSpecs] into DeviceMgr::
This is logically cleaner and it begins preparing our next set
of restructuring changes. To wit: we're revamping the device
manager to distinguish between devices and their roles.
2025-09-27 23:16:46 -04:00
hayodea 52567406ca Lockset: check for registration b4 unregistering 2025-09-27 22:22:35 -04:00
hayodea f8bf8083af Locking: Add contin tracing to detect deadlocks
We added the code to trace all the contins linked to a particular
Lockvoker, into SerializedAsyncContinuation. This basically
ensures that we'll almost never deal with a deadlock. So cool.
2025-09-27 20:51:20 -04:00
hayodea 782bcd4567 Async: add sh_ptr<ContinuationChainLink> to Callback<>
This change enables us to finally implement the tracing of
continuations backward from the point of acquisition for deadlock
debugging.
2025-09-27 18:30:09 -04:00
hayodea 09a0041f20 Squash: into debug locks intro commit 2025-09-22 21:29:43 -04:00
hayodea 092a0954a0 Locking: Add basic reactive deadlock detection foundation
We added a timestamp to each Lockvoker so that we can detect when
a lockvoker has been in a qutex for "too long", where "too long"
is defined arbitrarily as 500ms.

Next we're going to change the way we create callbacks to enable
us to more explicitly access the sh_ptr<AsyncContin> via
the callback object.
2025-09-22 20:45:36 -04:00
hayodea d2ed525106 Debug:Qutex: Add deadlock detection based on elapsed time
We now detect that a deadlock is likely when
CONFIG_DEBUG_QUTEX_DEADLOCK_TIMEOUT_MS has elapsed. This is the
preliminary work required to do a backtrace through the call
stack and figure out if a deadlock has really occured.

To do this, we'd have to go through the async call chain and
search for a previous caller which acquired the same qutex as
the one that first failed during this Lockvoker LockSet acquisition
attempt.
2025-09-21 15:11:28 -04:00
hayodea 329d57a16d Formatting 2025-09-20 18:23:03 -04:00
hayodea 32179eee5e Qutexes: Implement them and supporting classes
Implements: LockSet, SerializedAsynchronousContinuation,
	LockerAndInvoker, LockerAndInvokerBase, Qutex.

Very big leap in functionality here. See qutexes.md for
an explanation of what we've done.
2025-09-20 18:20:52 -04:00
hayodea 816a047920 Async: new hierachy; manages reply posting and unlocking
Async: Use new [Non]PostedAsyncCont and callOriginalCb

This new hierarchy of classes gives us a central mechanism for
managing both reply-posting and lockSpec unlocking.

* callOriginalCb: Now uses a modern C++ variadic template design
  enabling it to handle both direct calling and std::bind()
  re-binding of an arbitrary number of arguments from the caller.

This enables us to mostly eliminate the repeated, bespoke
definitions of callOriginalCb littered throughout the codebase.

We've also propagated these changes throughout the codebase in
this patch.
2025-09-17 16:38:48 -04:00
hayodea c52c447a78 Formatting 2025-09-16 18:46:30 -04:00
hayodea ddd6f6d6c6 CompThr: Comment on posted CBs 2025-09-16 18:45:55 -04:00
hayodea af33b7f097 SenseApiMgr: Make at/detachSenseDev & at/detachAllSenseDevs posted
They are posted to Marionette.

* We also fixed callOriginCb invocations;
* Also made posted CBs use std::bind instead of greedily
  early-invoking the CB on the servicing thread's stack.
2025-09-16 18:38:06 -04:00
hayodea 9e00cd1530 Formatting, indentation 2025-09-16 18:36:11 -04:00
hayodea 8fd8826f8d Mind:threadMgmt ops: move 0-iter callback to top 2025-09-16 18:24:16 -04:00
hayodea 429bd2a349 Exc: Replace with cb+ret 2025-09-16 15:10:28 -04:00
hayodea 5c79a89cd4 Body: Don't forget to finalizeAllLibs 2025-09-16 15:09:56 -04:00
hayodea a931f9f01a CompThr: Name segments to indicate that they're posted 2025-09-15 15:15:40 -04:00
hayodea 7f3bfec835 Mind:init/finiReq: now posted to mrntt; callbacks std:bind
We now have mind::initialize/finalizeReq post their requests
to Mrntt instead of executing on the caller's thread context.

We also fixed the way that we invoke callbacks by properly wrapping
it in a std::bind.
2025-09-15 15:01:26 -04:00
hayodea 19b39d391f DevMgr: Move helper function to top 2025-09-15 14:33:42 -04:00
hayodea 674d74cfb9 DevMgr:newDevSpecInd: fix posting and async pattern conformance 2025-09-15 14:32:26 -04:00
hayodea b768739b96 CompThr: Delete shutdownInd & exceptionInd
We no longer need them because we now have
mrntt::mrntt.finalizeReq(), which does a more holistic job of
shutting down Marionette (and thus, ultimately, Salmanoff).
2025-09-15 13:43:11 -04:00
hayodea db8f047322 SApiMgr:attDevReq: use body||world thread for i/e-devs
We now pass in the correct ComponentThread based on the type of
device that's being attached.
2025-09-15 12:47:37 -04:00
hayodea 472184bbbc Fix build errors with mind::globalMind and Qualia headers 2025-09-15 12:47:09 -04:00
hayodea 6573a1b14d CMake: delete subdir CMakeLists; use one CMakeList for smocore 2025-09-15 12:44:57 -04:00
hayodea 0759461c69 Mrntt:main: call mrntt:finalizeReq on exception
We'll wrap this in some exception-specific wrapper later.
2025-09-15 11:42:38 -04:00
hayodea e755383e72 Body: postfix _posted to posted sequence methods 2025-09-15 08:33:49 -04:00
hayodea d1e4c1a2ea Body:finalize: Will run if even one initReq step was executed
If even one step in Body.initializeReq was executed at all, then
whether or not it succeeded, we consider the body component to have
been initialized, at least with respect to whether finalizeReq
ought to run.
2025-09-15 08:30:17 -04:00
hayodea 29b192b2ee Formatting, spam-reduction 2025-09-15 08:25:49 -04:00
hayodea 7c48abbcca Body:init: Return true if any devices were initialized at all 2025-09-15 08:25:20 -04:00
hayodea 0ec227cf9e Body:finalize: Run even if body.init wasn't called
We now run body.finalizeReq even if body.init wasn't called. We'll
do a finer-grained check on each aspect of Body that needs to be
finalized now. This check was too large-grained.
2025-09-15 08:23:54 -04:00
hayodea baad2a9890 mrntt:main: Get rid of finalizeInd
This leverages the new clean dynamic allocation of the globalMind
object to make the mrntt::main and SMO's initialization and
shutdown much cleaner. We no longer concern ourselves with
shutting down the Mind threads inside of mrntt::main, but rather
we leave that state machine to the Mind class and Mrntt component.
2025-09-14 23:31:12 -04:00
hayodea 91ccd16b33 Add Mrntt component; init globalMind in mrntt.initializeReq
This makes the initialization sequence much cleaner and conceptually
well encapsulated.

We also now dynamically allocate the Mind objects. They're allocated
dynamically by Mrntt inside of initializeReq. This means that we no
longer have to worry about jolting and cleaning up the running threads
of global mind object even when we never explicitly called
Mind.initializeReq.

Along with other conceptual improvements to our abstractions, this
patch also gets us to a real "end of program initialization" point
for the first time.
2025-09-14 22:17:19 -04:00
hayodea 16865dc36f Rename these files and change ifdef guards 2025-09-14 13:16:02 -04:00
hayodea da0ef64f62 Split CompThread=>MindThr+MrnttThr; alloc globalMind in mrnttMain
We now allocate globalMind locally inside of marionetteMain. Why?

Before now, we had an asymmetric threading situation where the
globalMind's threads were initialized at during global constructor
invocation and not on demand. This meant that we had to shut down
those threads even if we had never got to the point of calling
Mind::initializeReq.

This significantly complicated our shutdown sequence since we had
to factor in the lifetime of the std::thread objects inside of the
ComponentThreads which were inside of the globalMind object.

Now, if we hadn't called Mind::initializeReq, we don't have to
perform any Mind::finalizeReq or adjacent operations. Shutdown is
symmetrically mirrored against the operations we actually performed
during execution.

We introduced some complexity by splitting ComponentThreads into
two derivative types (MindThread and MarionetteThread) but I think
in the long term we'll be able to massage this split into a much
cleaner situation overall.
2025-09-14 11:07:05 -04:00
hayodea 7cb6c8521e MindThread:shutdownInd: explicitly invoke on globalMind 2025-09-14 10:59:52 -04:00
hayodea 1d3d929ddd Mind: Use state variables to manage shutdown
We now allow the shutdown*Req() methods of Mind:: to return early
if their aspect of the object in question hasn't actually been
initialized.
2025-09-13 18:59:44 -04:00
hayodea 25a9721f92 Mind: Implement initialize/finalizeBodyReq()
We've done a lot of general work on the init sequencing.
2025-09-12 16:09:26 -04:00