[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