X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 7A277385E000
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1584907807;
	bh=wuSGgeeRkzNH3/SGed1xPjCAed+E8mwW4ypJUmtkw2o=;
	h=Subject:From:To:Date:In-Reply-To:References:List-Id:
	List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	From;
	b=PMYB/lGBc4fcGbxMAQOak8nIka1JmBwrRvojSieVBCY6mSSpuFRiJoy13ZPJyEjNQ
	cU25nzA8XsfXQreRwDNQCuC2F1MLVoIwa+i1FQ2M17M19jLI94N4BD15Kyvfc866u8
	Wegv/fwFKJXG8znEIj3Jtzqk/MsDpkz/3cha8JWc=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
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 AT cygwin DOT com
X-MC-Unique:	hG7LMpB3Oz2EJKSoI1ZArw-1
Message-ID:	<6f93f54eafe911f7d9b8c1319ebdefedb50f6fa6.camel@cygwin.com>
Subject:	Re: Why is taskset still not in util-linux?
From:	Yaakov Selkowitz <yselkowitz AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Date:	Sun, 22 Mar 2020 16:09:59 -0400
In-Reply-To:	<f50b2040-c29f-9983-9bce-d1c33fb4bae7@maxrnd.com>
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>
	<dca24f26-9da9-591c-19c1-8020e5de3a4e AT maxrnd DOT com>
	<79d7afa5-a07b-04df-c259-b76c61390f8c AT maxrnd DOT com>
	<c075b981d41ff880e0af76c853e764c468b9c6de DOT camel AT cygwin DOT com>
	<dd8104f5-4a76-1ff3-f769-69154991aa80 AT cs DOT umass DOT edu>
	<f50b2040-c29f-9983-9bce-d1c33fb4bae7 AT maxrnd DOT 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
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 AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	Cygwin mailing list <cygwin.cygwin.com>
List-Unsubscribe:	<http://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<http://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<http://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

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:
> > 
> >  > 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.

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 when 
> you've come across it in all the porting you've done?  Cygwin-specific patch?

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

--
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

- Raw text -