Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tml <tarantool-patches@freelists.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Konstantin Osipov <kostja@tarantool.org>
Subject: Re: [PATCH] box/memtx: strip_core -- Warn on linux only
Date: Fri, 30 Aug 2019 01:16:15 +0300	[thread overview]
Message-ID: <20190829221614.2ohizp2ffdz4vcoa@tkn_work_nb> (raw)
In-Reply-To: <20190829185543.GA2801@uranus.lan>

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.

  reply	other threads:[~2019-08-29 22:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28 18:13 Cyrill Gorcunov
2019-08-29 10:39 ` [tarantool-patches] " Konstantin Osipov
2019-08-29 12:19 ` Alexander Turenko
2019-08-29 18:55   ` Cyrill Gorcunov
2019-08-29 22:16     ` Alexander Turenko [this message]
2019-08-30  7:24       ` Cyrill Gorcunov
2019-08-29 19:28 ` [tarantool-patches] " Kirill Yukhin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190829221614.2ohizp2ffdz4vcoa@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=gorcunov@gmail.com \
    --cc=kostja@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=vdavydov.dev@gmail.com \
    --subject='Re: [PATCH] box/memtx: strip_core -- Warn on linux only' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox