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