From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 0D2DC385E000 for ; Sun, 22 Mar 2020 20:10:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0D2DC385E000 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=yselkowitz@cygwin.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-54-hG7LMpB3Oz2EJKSoI1ZArw-1; Sun, 22 Mar 2020 16:10:02 -0400 X-MC-Unique: hG7LMpB3Oz2EJKSoI1ZArw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3FE60100550D for ; Sun, 22 Mar 2020 20:10:01 +0000 (UTC) Received: from ovpn-112-56.rdu2.redhat.com (ovpn-112-56.rdu2.redhat.com [10.10.112.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CEBCA196AE for ; Sun, 22 Mar 2020 20:10:00 +0000 (UTC) Message-ID: <6f93f54eafe911f7d9b8c1319ebdefedb50f6fa6.camel@cygwin.com> Subject: Re: Why is taskset still not in util-linux? From: Yaakov Selkowitz To: cygwin@cygwin.com Date: Sun, 22 Mar 2020 16:09:59 -0400 In-Reply-To: References: <1348011a-261a-2a87-d361-4e51fa8dc19f@cs.umass.edu> <85ae12aa-6cc3-5d4c-5df2-25bf811ec6a9@maxrnd.com> <72fea68a-b3d7-e87c-726f-8a5a2587a992@maxrnd.com> <01e3d337-e5fe-f393-7634-3f1881bca315@cs.umass.edu> <79d7afa5-a07b-04df-c259-b76c61390f8c@maxrnd.com> User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cygwin.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-15.0 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NEUTRAL, 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 20:10:06 -0000 On Sat, 2020-03-21 at 01:37 -0700, Mark Geisert wrote: > Eliot Moss wrote: > > On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote: > >=20 > > > Cygwin doesn't support syscalls. I'd be very wary of any code which= is > > > conditional on any #ifdef SYS_*. > >=20 > > 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 o= f 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. >=20 > What I did here was definitely a hack. I'm not sure it's the best soluti= on. >=20 > I fully concur with Yaakov's warning. There's two levels to syscalls as = seen in=20 > programs like taskset. On one level, configure checks whether a particul= ar=20 > syscall exists on the compiling machine because different Linux kernels h= ave=20 > different sets of syscalls. On the second level, the program actually us= es a=20 > call named syscall() to call into specific kernel routines. >=20 > On Cygwin, what to do about programs that assume they're running on Linux= and so=20 > make use of the Linux syscall feature? We could dummy up a sys/syscall.h= but=20 > implementing a full syscall() interface would be a lot of work and do not= hing=20 > but slow down programs making heavy use of it; it adds a layer of indirec= tion. I have considered doing just that on multiple occasions, but never got so desperate for it to bother. Keep in mind that kernel APIs often vary from their userspace wrappers (which is one of the two reasons userspace code calls syscall, the other being to access yet-unwrapped calls), meaning such an implementation wouldn't be a simple mapping to existing userspace functions. However, I wouldn't worry so much about performance, the point would be compatibility. > Yaakov, do you have a general strategy for dealing with syscall usage whe= n=20 > you've come across it in all the porting you've done? Cygwin-specific pa= tch? That depends very much on what the code is trying to do (and which syscalls it wants to call!), but using #ifdef SYS_* to guard use of the corresponding userspace function call might be a first. There are definitely some of my packages which I had to patch around syscall assumptions, but I'd have to go find them. -- Yaakov