X-Recipient: archive-cygwin AT delorie DOT com X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1A983394D833 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark AT maxrnd DOT com Subject: Re: Why is taskset still not in util-linux? To: moss AT cs DOT umass DOT edu, cygwin References: <1348011a-261a-2a87-d361-4e51fa8dc19f AT cs DOT umass DOT edu> <85ae12aa-6cc3-5d4c-5df2-25bf811ec6a9 AT maxrnd DOT com> <72fea68a-b3d7-e87c-726f-8a5a2587a992 AT maxrnd DOT com> <01e3d337-e5fe-f393-7634-3f1881bca315 AT cs DOT umass DOT edu> <79d7afa5-a07b-04df-c259-b76c61390f8c AT maxrnd DOT com> From: Mark Geisert Message-ID: Date: Sat, 21 Mar 2020 01:37:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 02L8dOOa012492 Eliot Moss wrote: > On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote: > > > Cygwin doesn't support syscalls.  I'd be very wary of any code which is > > conditional on any #ifdef SYS_*. > > Of course.  AFAICT taskset does not need the syscall, it just needs the > library call to work.  Asking about the syscall is, I suppose, a kind of Linux > shorthand to see if something is supported on the particular platform.  Mark's > suggestion of providing a fake definition of that syscall definition is a > workaround that may disturb the util-linux sources the least. What I did here was definitely a hack. I'm not sure it's the best solution. I fully concur with Yaakov's warning. There's two levels to syscalls as seen in programs like taskset. On one level, configure checks whether a particular syscall exists on the compiling machine because different Linux kernels have different sets of syscalls. On the second level, the program actually uses a call named syscall() to call into specific kernel routines. On Cygwin, what to do about programs that assume they're running on Linux and so make use of the Linux syscall feature? We could dummy up a sys/syscall.h but implementing a full syscall() interface would be a lot of work and do nothing but slow down programs making heavy use of it; it adds a layer of indirection. Yaakov, do you have a general strategy for dealing with syscall usage when you've come across it in all the porting you've done? Cygwin-specific patch? ..mark -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple