Dark-Horse-Linux/dpm-core-ng
3
0
Fork 0
Code Issues Pull Requests Actions Activity

One way to record an error, and a name that reads as a query

Browse Source 
dpm_module_info_of becomes dpm_get_module_info, joining the other two
readers on the context in stating that a call fetches a value.

Recording an error had two entry points doing the same write: the
exported dpm_set_last_error and an internal dpm_core::set_last_error
taking a std::string. The internal one is gone and the loader calls the
exported function, so a reason reaches the context by one path whether a
module or the library records it.
This commit is contained in:
Chris Punches
2026-08-19 02:34:28 -04:00
parent 50d71ca55f
commit 71d409b5c7
9 changed files with 21 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/PROSE/MODULES.md
View File

@@ -60,7 +60,7 @@ The `ctx` is the one handed to your entry point. Nothing else is needed to reach
**Never link, include, or hardcode anything belonging to a peer.** No peer headers, no shared types, no peer symbols. Modules are loaded with `RTLD_LOCAL`, so a peer's symbols are not reachable from your module even if you tried — libdpm-core.so is the only path, and the only knowledge you hold about a peer is its name and the commands it documents.
A module that depends on a peer is the party that judges the peer's version. Require it, read its reported version with `dpm_module_info_of`, and decide whether it is suitable for the commands you intend to issue. libdpm-core.so reports; it does not rule.
A module that depends on a peer is the party that judges the peer's version. Require it, read its reported version with `dpm_get_module_info`, and decide whether it is suitable for the commands you intend to issue. libdpm-core.so reports; it does not rule.
## Validation at Load