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