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 3F859394D833
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 AT cygwin DOT 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>
	<92157259-166d-a85d-2db7-a8e30c75ec09 AT cs DOT umass DOT edu>
From:	Mark Geisert <mark AT maxrnd DOT com>
Message-ID:	<99d74893-f9f8-4d8d-a400-dfe247660bf0@maxrnd.com>
Date:	Sat, 21 Mar 2020 01:18:24 -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:	<92157259-166d-a85d-2db7-a8e30c75ec09@cs.umass.edu>
X-Spam-Status:	No, score=-14.5 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
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>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 02L8J4jl010295

Eliot Moss wrote:
> On 3/20/2020 1:54 AM, Mark Geisert wrote:
> 
>  > I've reproduced your snags.  It/they are due to my having forgotten another 
> tiny update that should
>  > have been part of the 2.33.1-cygwin-cpuset.patch file.  If you 'echo "#define 
> SYS_sched_getaffinity
>  > 42" > /usr/local/include/sys/syscall.h' and then back out your other fix 
> attempts, the build using
>  > cygport should work.
> 
> Dear Mark:
> 
> Once I did that properly, it built without commenting out that test.  Yay!

Great!
> We still need to suppress building ionice, which requires patching
> configure.ac to provide a separate flag for that.  And we still need to
> #define _GNU_SOURCE before the #include <sched.h> to make the
> sched_get/setaffinity calls visible.  I intend to patch that into taskset.c
> unless you have a better way of doing it.

I still don't get why these are happening for you.  You're building util-linux 
2.33.1, right?  Here's where the ionice build step is rejected by configure on 
my system (from config.log in the build directory):

| #include <sys/syscall.h>
| #include <unistd.h>
|
| int
| main ()
| {
| int test = _NR_ioprio_set;
|   ;
|   return 0;
| }
configure:30512: result: no
configure:30515: WARNING: Unable to detect syscall ioprio_set.
configure:30531: WARNING: ioprio_set syscall not found; not building ionice

As far as the missing _GNU_SOURCE #define, that same config.log just a page or 
two up lists the contents of confdefs.h and therein _GNU_SOURCE is #defined 1.

Are you doing a 'cygport clean' between build attempts?

> When I do all this and use 'cygport compile', I get a taskset that appears to
> work ...  as long as I run it in the place where it was built.  When I install
> it, it fails, pretty silently.  I have strace outputs from the two cases, but
> don't know enough about internals to interpret them.  It seems that the
> failure is errno 2, ENOENT.

I don't install taskset.exe, I just manually copy the exe into /usr/local/bin. 
Not that that should matter.  The Cygwin-level affinity functions don't set 
ENOENT, but there might be an underlying Windows affinity function that returns 
an error that Cygwin maps to ENOENT.

> The permissions on the file in the build area and the one in /usr/bin are the
> same (according to both getfacl and icacls) and they are on the same drive.
> 'cmp' indicates that the file contents are the same.  It's pretty confusing.
> I've never seen anything like it.  It doesn't matter if I give the full path
> '/usr/bin/taskset' or the shorter 'taskset'.  The containing directories have
> slightly different permissions, but lots of other files in /usr/bin load and
> run.

No idea why it runs in one place but not the other.  Other than what might be in 
your PATH.  You might try running 'ldd' on each exe and making sure they're 
using the same libraries... How could they not?  Dunno.  Also do 'echo $?' after 
a run to see what error code the exe is exiting with.

> By running the version in the build directory on a somewhat long-running ls
> command, and using taskset -p on that running ls from another window, I
> verified that the affinity mask is indeed getting set.  (It was less obvious
> to me how to tell which cpu it was actually running on.)

I ended up installing Process Lasso to follow processes among the cpus and to 
test the Cygwin affinity mask implementation.  It has a free trial period.  And 
I wrote a simple test program that just advances from one cpu to the next 
repeatedly, cpu-bound between steps, so PL can display the changing cpu.

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

- Raw text -