From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 30 Aug 2019 01:16:15 +0300 From: Alexander Turenko Subject: Re: [PATCH] box/memtx: strip_core -- Warn on linux only Message-ID: <20190829221614.2ohizp2ffdz4vcoa@tkn_work_nb> References: <20190828181322.16768-1-gorcunov@gmail.com> <20190829121905.h6v6hfheq6g3ejhy@tkn_work_nb> <20190829185543.GA2801@uranus.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190829185543.GA2801@uranus.lan> To: Cyrill Gorcunov Cc: tml , Vladimir Davydov , Konstantin Osipov List-ID: 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.