Hi
On 3/16/26 06:03, [email protected] wrote:
I believe that the process is to send a message to the list, and gauge whether
there is positive feedback before creating the RFC for voting. Please let me
know if I should create the RFC first?
The PR is here: https://github.com/php/php-src/pull/21452/changes
I suspect that SNMP is such a specialized and rarely used extension that
folks will be unable to meaningfully discuss an RFC for this feature -
at least not without you doing quite a bit of explaining. This might be
case where it's best to just find an informal agreement with you
providing a well-tested and well-explained patch rather than doing a
full RFC.
----------
That said, I did some research, finding this man page:
https://linux.die.net/man/3/shutdown_mib.
I'm seeing that the manpage states for init_mib():
It should be called before any other routine that manipulates or accesses the MIB tree.
I'm seing that init_mib() is not currently called at all in ext/snmp. Is
the initialization implicitly happening as part of init_snmp()?
For shutdown_mib() I'm seeing:
It is strongly recommended that one does not invoke shutdown_mib while there
are SNMP sessions being actively managed.
Will calling your proposed `snmp_init_mib()` function cause issues when
an existing SNMP object is being used after the call to `snmp_init_mib()`?
----------
In your email you mention:
Another consideration is that the MIB tree persists across FPM requests because
the MIB tree is kept as a global structure within SNMP library memory.
Would calling `shutdown_mib()` in RSHUTDOWN (i.e. the end-of-request
handler) solve the problem of the MIB persisting across requests or is
it sometimes desirable that the MIB is persisted?
Best regards
Tim Düsterhus
