[PATCH] box/memtx: strip_core -- Warn on linux only
Alexander Turenko
alexander.turenko at tarantool.org
Fri Aug 30 01:16:15 MSK 2019
On Thu, Aug 29, 2019 at 09:55:43PM +0300, Cyrill Gorcunov wrote:
> On Thu, Aug 29, 2019 at 03:19:05PM +0300, Alexander Turenko wrote:
> ...
> >
> > I think it is okay: it is the minor thing and an easiest way to solve is
> > the better way.
> >
> > If we'll have more OS dependent features (hopefully we'll not), then
> > maybe it will be worth to do two things:
> >
> > * Check whether a user asks to enable something explicitly (or it was
> > set by default); give a warning only for an explicit choose.
>
> We will need to track then how exactly the feature is set up -- currently
> we simply don't have such ability. IOW, we will need two seprate tables:
> one for default values and second for runtime values. If it is acceptable
> I could try to implement it.
I think that this certain issue is not enough reason to do so.
>
> > * Check whether libsmall was compiled with a feature supported and don't
> > give a warning if a tarantool build does not support a feature on a
> > platform at all (it is instead of TARGET_OS_LINUX check).
>
> Wait, do you propose to do similar compile-time check for madvise
> feature inside tarantool code?
I imagine it as two functions in small: one for check whether madvise is
compiled-in (i.e. it is expected to be supported on a platform) and
another (existing now) whether it is actually works. After that we can
separately check 'is it supported on a platform' and 'is it works' from
tarantool code to implement the logic described below.
Anyway, I would not bother with all this stuff until at least one
another feature will require something like that.
>
> > Those bullets implemented will give us the following logic: give a
> > warning only if a user explicitly asks a feature AND it is supported on
> > a platform AND it is not supported at runtime.
>
> Sounds reasonable.
More information about the Tarantool-patches
mailing list