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.
next prev parent 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