I believe that `NS_PLUGIN_VERSION` is reserved for situations where the **plugin** API itself changes. But I agree with you that the current situation where the query_ctx_t struct members are accessed directly isn't ideal.
My recommendation would be to recompile the plugin together with each new BIND 9 version. I am open to any suggestions, but I think the having a GitLab issue would be a better venue to record any ideas around the plugin system. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 15. 12. 2022, at 21:47, Marcus Kool <marcus.k...@urlfilterdb.com> wrote: > > Hi Ondrej, > > yeah, I was kinda expecting "no guarantees", but isn't the plugin_version() > function a good method candidate to enforce compatibility? > I mean, isn't increasing NS_PLUGIN_VERSION when a (plugin visible) data > structure changes, a good way to enforce that only compatible plugins are > used? > > Thanks, > > Marcus > > > > On 15/12/2022 19:32, Ondřej Surý wrote: >> Hi Marcus, >> >> I am afraid that we can’t provide any guarantees about the BIND 9 internal >> libraries. We made a decision to drop the layers and layers of compatibility >> for the sake of maintainability. >> >> That said, once the release is pronounced ESV (roughly a year from initial >> release), we try to minimize changes to that branch, but it could still >> happen if needed by a security fix. >> >> As for the binary compatibility, there’s no guarantee whatsoever, I think >> you need to match the full version to check whether the plug-in should be >> loaded. >> >> Honestly, the best way how to keep the plug-in that’s useful for wider >> audience maintained would be to contribute it to the BIND 9 with a promise >> that the authors will keep helping maintaining the plug-in. (We would like >> to avoid the situations where the author just dumps the code on us and don’t >> care anymore - there’s associated maintenance cost with any new feature.) >> >> Ondrej >> -- >> Ondřej Surý — ISC (He/Him) >> >> My working hours and your working hours may be different. Please do not feel >> obligated to reply outside your normal working hours. >> >>> On 15. 12. 2022, at 20:10, Marcus Kool <marcus.k...@urlfilterdb.com> >>> <mailto:marcus.k...@urlfilterdb.com> wrote: >>> >>> >>> Hi, >>> >>> I have written a plugin for named and was wondering what the policy behind >>> the usage of plugin_version() is and what kind of compatibility check it >>> intends to perform. >>> >>> It is common for plugins to use query_ctx_t and its members fname, view, >>> client (client.message, client.query) etc. >>> Since these data structures may change between (patch) versions, a plugin >>> compiled for version A can get a SEGV signal because a data structure >>> changed and the plugin is used inside named version B. >>> I have little experience with data structure changes of named and observed >>> only the addition of refresh_rrset in query_ctx (somewhere between 9.16.1 >>> and 9.16.35) which did not cause an issue since its 1-byte size did not >>> change offsets of most members inside the query_ctx struct. >>> >>> In our plugin, plugin_register() checks for the major and minor version >>> number in named_g_version so a plugin compiled with 9.16.x refuses to >>> initialize inside a 9.18.y named process and vice versa. But I have the >>> impression that this might not be a 100% guarantee that all is well. >>> >>> Because we like to release as few as possible versions of the plugin I have >>> a second question: how can we be sure that a plugin compiled with 9.X.1 >>> will have no issues accessing named data structures for all patch versions >>> of 9.X? >>> >>> Thanks, >>> >>> Marcus >>> >>> >>> >>> >>> >>> -- >>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from >>> this list >>> >>> ISC funds the development of this software with paid support subscriptions. >>> Contact us at https://www.isc.org/contact/ for more information. >>> >>> >>> bind-users mailing list >>> bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> >>> https://lists.isc.org/mailman/listinfo/bind-users > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
