You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Walt Karas <wk...@oath.com.INVALID> on 2018/03/27 22:08:07 UTC
Making BufferWriter.h available to C++ ATS plugins
If we make BufferWriter.h available to C++ plugins, we would also have
to make all of these header files available to plugins:
MemSpan.h
ink_assert.h
BufferWriterForward.h
ink_apidefs.h
ink_error.h
ink_std_compat.h
ink_platform.h
ink_config.h
ink_autoconf.h
Scary right? Or not so much?
Re: Making BufferWriter.h available to C++ ATS plugins
Posted by Walt Karas <wk...@oath.com.INVALID>.
OK, I took a stab at one approach to this issue:
https://github.com/apache/trafficserver/pull/3361
But the ABI vs. API issue is not addressed by this.
On Tue, Mar 27, 2018 at 8:45 PM, Alan Carroll
<so...@oath.com.invalid> wrote:
> That's a bit much. Let me take a look at how it could be refactored to
> reduce the dependencies.
>
> On Tue, Mar 27, 2018 at 6:02 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>>
>> > On Mar 27, 2018, at 4:54 PM, Walt Karas <wk...@oath.com.INVALID> wrote:
>> >
>> > Is there any ways to ensure ABI compatibility other than to compile
>> > the plugin and the core with the same compiler and same options?
>>
>> Well, we can’t change things such as orders within enum / structs in the
>> core for an example of an ABI incompatible change. IF those enum’s /
>> structs are exposed. We went through a refactoring for this exact reason,
>> to make sure that the core and plugins use the same versions of such
>> things, that’s why we have #include <ts/apidefs.h> now.
>>
>> API incompatibilities are of course easier to detect / notice, but I
>> suspect the concern raised here would be that we break something in those
>> many include files, that changes the ABI for the plugins. I can’t give an
>> example, but something to look at.
>>
>> Cheers,
>>
>> — leif
>>
>> >
>> > On Tue, Mar 27, 2018 at 5:51 PM, Leif Hedstrom <zw...@apache.org> wrote:
>> >>
>> >>
>> >>> On Mar 27, 2018, at 4:23 PM, Walt Karas <wk...@oath.com.INVALID>
>> wrote:
>> >>>
>> >>> With some tricky symbolic links, I could probably arrive at a solution
>> >>> where these header would be exported (to plugins) in include/detail or
>> >>> something, not include/ts, so plugins writers would know not to
>> >>> include them directly.
>> >>
>> >>
>> >>
>> >> It also means that whatever APIs you *do* expose to plugins from hereon
>> must be API and ABI compatible within the major releases.
>> >>
>> >> — leif
>> >>
>>
>>
Re: Making BufferWriter.h available to C++ ATS plugins
Posted by Alan Carroll <so...@oath.com.INVALID>.
That's a bit much. Let me take a look at how it could be refactored to
reduce the dependencies.
On Tue, Mar 27, 2018 at 6:02 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On Mar 27, 2018, at 4:54 PM, Walt Karas <wk...@oath.com.INVALID> wrote:
> >
> > Is there any ways to ensure ABI compatibility other than to compile
> > the plugin and the core with the same compiler and same options?
>
> Well, we can’t change things such as orders within enum / structs in the
> core for an example of an ABI incompatible change. IF those enum’s /
> structs are exposed. We went through a refactoring for this exact reason,
> to make sure that the core and plugins use the same versions of such
> things, that’s why we have #include <ts/apidefs.h> now.
>
> API incompatibilities are of course easier to detect / notice, but I
> suspect the concern raised here would be that we break something in those
> many include files, that changes the ABI for the plugins. I can’t give an
> example, but something to look at.
>
> Cheers,
>
> — leif
>
> >
> > On Tue, Mar 27, 2018 at 5:51 PM, Leif Hedstrom <zw...@apache.org> wrote:
> >>
> >>
> >>> On Mar 27, 2018, at 4:23 PM, Walt Karas <wk...@oath.com.INVALID>
> wrote:
> >>>
> >>> With some tricky symbolic links, I could probably arrive at a solution
> >>> where these header would be exported (to plugins) in include/detail or
> >>> something, not include/ts, so plugins writers would know not to
> >>> include them directly.
> >>
> >>
> >>
> >> It also means that whatever APIs you *do* expose to plugins from hereon
> must be API and ABI compatible within the major releases.
> >>
> >> — leif
> >>
>
>
Re: Making BufferWriter.h available to C++ ATS plugins
Posted by Leif Hedstrom <zw...@apache.org>.
> On Mar 27, 2018, at 4:54 PM, Walt Karas <wk...@oath.com.INVALID> wrote:
>
> Is there any ways to ensure ABI compatibility other than to compile
> the plugin and the core with the same compiler and same options?
Well, we can’t change things such as orders within enum / structs in the core for an example of an ABI incompatible change. IF those enum’s / structs are exposed. We went through a refactoring for this exact reason, to make sure that the core and plugins use the same versions of such things, that’s why we have #include <ts/apidefs.h> now.
API incompatibilities are of course easier to detect / notice, but I suspect the concern raised here would be that we break something in those many include files, that changes the ABI for the plugins. I can’t give an example, but something to look at.
Cheers,
— leif
>
> On Tue, Mar 27, 2018 at 5:51 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>
>>> On Mar 27, 2018, at 4:23 PM, Walt Karas <wk...@oath.com.INVALID> wrote:
>>>
>>> With some tricky symbolic links, I could probably arrive at a solution
>>> where these header would be exported (to plugins) in include/detail or
>>> something, not include/ts, so plugins writers would know not to
>>> include them directly.
>>
>>
>>
>> It also means that whatever APIs you *do* expose to plugins from hereon must be API and ABI compatible within the major releases.
>>
>> — leif
>>
Re: Making BufferWriter.h available to C++ ATS plugins
Posted by Walt Karas <wk...@oath.com.INVALID>.
Is there any ways to ensure ABI compatibility other than to compile
the plugin and the core with the same compiler and same options?
On Tue, Mar 27, 2018 at 5:51 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
>> On Mar 27, 2018, at 4:23 PM, Walt Karas <wk...@oath.com.INVALID> wrote:
>>
>> With some tricky symbolic links, I could probably arrive at a solution
>> where these header would be exported (to plugins) in include/detail or
>> something, not include/ts, so plugins writers would know not to
>> include them directly.
>
>
>
> It also means that whatever APIs you *do* expose to plugins from hereon must be API and ABI compatible within the major releases.
>
> — leif
>
Re: Making BufferWriter.h available to C++ ATS plugins
Posted by Leif Hedstrom <zw...@apache.org>.
> On Mar 27, 2018, at 4:23 PM, Walt Karas <wk...@oath.com.INVALID> wrote:
>
> With some tricky symbolic links, I could probably arrive at a solution
> where these header would be exported (to plugins) in include/detail or
> something, not include/ts, so plugins writers would know not to
> include them directly.
It also means that whatever APIs you *do* expose to plugins from hereon must be API and ABI compatible within the major releases.
— leif
Re: Making BufferWriter.h available to C++ ATS plugins
Posted by Walt Karas <wk...@oath.com.INVALID>.
With some tricky symbolic links, I could probably arrive at a solution
where these header would be exported (to plugins) in include/detail or
something, not include/ts, so plugins writers would know not to
include them directly.
On Tue, Mar 27, 2018 at 5:15 PM, Derek Dagit <de...@oath.com.invalid> wrote:
> One reason this could be scary is that should we change any of these
> headers going forward, it could mean a backward-incompatible release for
> ATS.
>
> In-place upgrades may not be possible for administrators without
> recompiling their plugins.
>
> On Tue, Mar 27, 2018 at 5:08 PM, Walt Karas <wk...@oath.com.invalid> wrote:
>
>> If we make BufferWriter.h available to C++ plugins, we would also have
>> to make all of these header files available to plugins:
>>
>> MemSpan.h
>> ink_assert.h
>> BufferWriterForward.h
>> ink_apidefs.h
>> ink_error.h
>> ink_std_compat.h
>> ink_platform.h
>> ink_config.h
>> ink_autoconf.h
>>
>> Scary right? Or not so much?
>>
>
>
>
> --
> Derek
Re: Making BufferWriter.h available to C++ ATS plugins
Posted by Derek Dagit <de...@oath.com.INVALID>.
One reason this could be scary is that should we change any of these
headers going forward, it could mean a backward-incompatible release for
ATS.
In-place upgrades may not be possible for administrators without
recompiling their plugins.
On Tue, Mar 27, 2018 at 5:08 PM, Walt Karas <wk...@oath.com.invalid> wrote:
> If we make BufferWriter.h available to C++ plugins, we would also have
> to make all of these header files available to plugins:
>
> MemSpan.h
> ink_assert.h
> BufferWriterForward.h
> ink_apidefs.h
> ink_error.h
> ink_std_compat.h
> ink_platform.h
> ink_config.h
> ink_autoconf.h
>
> Scary right? Or not so much?
>
--
Derek