<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>I believe that `NS_PLUGIN_VERSION` is reserved for situations</div><div>where the **plugin** API itself changes. But I agree with you that</div><div>the current situation where the query_ctx_t struct members are</div><div>accessed directly isn't ideal.</div><div><br></div><div>My recommendation would be to recompile the plugin together</div><div>with each new BIND 9 version.</div><div><br></div><div>I am open to any suggestions, but I think the having a GitLab</div><div>issue would be a better venue to record any ideas around the</div><div>plugin system.</div><div><br></div>Ondrej<br><div>
<meta charset="UTF-8"><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">--</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Ondřej Surý (He/Him)</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">ondrej@isc.org</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.</div></div></div></div>
</div>
<br><br><div><br><blockquote type="cite"><div>On 15. 12. 2022, at 21:47, Marcus Kool <marcus.kool@urlfilterdb.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div><p>Hi Ondrej,</p><p>yeah, I was kinda expecting "no guarantees", but isn't the
plugin_version() function a good method candidate to enforce
compatibility?<br>
I mean, isn't increasing <span style="font-family:monospace"><span style="background-color: rgb(255, 255, 255);">NS_PLUGIN</span><span style="background-color: rgb(178, 104, 24);">_VERSI</span><span style="background-color: rgb(255, 255, 255);">ON</span></span>
when a (plugin visible) data structure changes, a good way to
enforce that only compatible plugins are used?<span style="background-color: rgb(255, 255, 255);"><br>
</span></p><p><span style="background-color: rgb(255, 255, 255);">Thanks,</span></p><p><span style="background-color: rgb(255, 255, 255);">Marcus<br>
</span></p><p><span style="font-family:monospace"><br>
</span></p>
<div class="moz-cite-prefix">On 15/12/2022 19:32, Ondřej Surý wrote:<br>
</div>
<blockquote type="cite" cite="mid:D4B1488F-1A1C-4639-80BE-8513F959C860@isc.org">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi Marcus,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>Ondrej<br>
<div dir="ltr">
<div>--</div>
Ondřej Surý — ISC (He/Him)
<div><br>
</div>
<div>My working hours and your working hours may be different.
Please do not feel obligated to reply outside your normal
working hours.</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On 15. 12. 2022, at 20:10, Marcus Kool
<a class="moz-txt-link-rfc2396E" href="mailto:marcus.kool@urlfilterdb.com"><marcus.kool@urlfilterdb.com></a> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8"><p>Hi,</p><p>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.</p><p>It is common for plugins to use query_ctx_t and its
members fname, view, client (client.message, client.query)
etc.<br>
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.<br>
I have little experience with data structure changes of
named and observed only the addition of <font face="monospace">refresh_rrset</font> 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.</p><p>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.<br>
</p><p>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?</p><p>Thanks,</p><p>Marcus</p><p><br>
</p><p><span style="font-family:monospace"><br>
</span></p>
<span>-- </span><br>
<span>Visit
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to
unsubscribe from this list</span><br>
<span></span><br>
<span>ISC funds the development of this software with paid
support subscriptions. Contact us at
<a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.</span><br>
<span></span><br>
<span></span><br>
<span>bind-users mailing list</span><br>
<span><a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a></span><br>
<span><a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></span><br>
</div>
</blockquote>
</div>
</blockquote>
</div>
-- <br>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list<br><br>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br><br><br>bind-users mailing list<br>bind-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/bind-users<br></div></blockquote></div><br></body></html>