Why is taskset still not in util-linux?

Why is taskset still not in util-linux?

[Eliot Moss]

Dear cygwin-ers --

Something I had asked about a while ago was the absence os taskset in cygwin's
util-linux.  At the time, it was pointed out that the necessary get/set
affinity library/system calls were not yet supported.  These were added a
while ago, so it would seem that taskset ought to work.  In fact, I think
someone got it going on their own.  Can we add it to util-linux now,
officially?  I think this was intended but perhaps was overlooked or
something.

Regards - Eliot Moss

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is taskset still not in util-linux?

[Mark Geisert]

Eliot Moss wrote:
> 
> Dear cygwin-ers --
> 
> Something I had asked about a while ago was the absence os taskset in cygwin's
> util-linux.  At the time, it was pointed out that the necessary get/set
> affinity library/system calls were not yet supported.  These were added a
> while ago, so it would seem that taskset ought to work.  In fact, I think
> someone got it going on their own.  Can we add it to util-linux now,
> officially?  I think this was intended but perhaps was overlooked or
> something.

Report noted; thanks.  A solution is being worked.

..mark

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Why is taskset still not in util-linux?

[Mark Geisert]

Mark Geisert wrote:
> Eliot Moss wrote:
>>
>> Dear cygwin-ers --
>>
>> Something I had asked about a while ago was the absence os taskset in cygwin's
>> util-linux.  At the time, it was pointed out that the necessary get/set
>> affinity library/system calls were not yet supported.  These were added a
>> while ago, so it would seem that taskset ought to work.  In fact, I think
>> someone got it going on their own.  Can we add it to util-linux now,
>> officially?  I think this was intended but perhaps was overlooked or
>> something.
> 
> Report noted; thanks.  A solution is being worked.

There's been no forward progress on this.  If you're comfortable getting the 
util-linux source package through Cygwin setup*.exe, you can follow the steps 
shown in https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to 
build (with cygport) a local copy of util-linux that includes a taskset.exe you 
can move into /usr/local/bin, for example.

You might try that route if you're up for it.  Feel free to ask questions here 
if you hit a snag.
HTH,

..mark

Re: Why is taskset still not in util-linux?

[Eliot Moss]

On 3/16/2020 7:34 PM, Mark Geisert wrote:
 > Mark Geisert wrote:
 >> Eliot Moss wrote:
 >>>
 >>> Dear cygwin-ers --
 >>>
 >>> Something I had asked about a while ago was the absence os taskset in cygwin's
 >>> util-linux.  At the time, it was pointed out that the necessary get/set
 >>> affinity library/system calls were not yet supported.  These were added a
 >>> while ago, so it would seem that taskset ought to work.  In fact, I think
 >>> someone got it going on their own.  Can we add it to util-linux now,
 >>> officially?  I think this was intended but perhaps was overlooked or
 >>> something.
 >>
 >> Report noted; thanks.  A solution is being worked.
 >
 > There's been no forward progress on this.  If you're comfortable getting the util-linux source
 > package through Cygwin setup*.exe, you can follow the steps shown in
 > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build (with cygport) a local copy
 > of util-linux that includes a taskset.exe you can move into /usr/local/bin, for example.
 >
 > You might try that route if you're up for it.  Feel free to ask questions here if you hit a snag.
 > HTH,

Thank you, Mark.  I decided to give it a try and got some distance, but hit a snag.

First, I had to change configure.ac to add control to disable ionice (Cygwin
does not support a required syscall) while still trying to build taskset.
Previously taskset and ionice (and one other program) were controlled by the
single --enable-schedutils.

Now, including sched.h does not provide the prototypes for sched_getaffinity,
etc.  I found a previous post that suggests we need to do -D_GNU_SOURCE for it
to work.  I am not sure of the best place to stick that, but I will see about
maybe a one line patch to taskset.c or something.

Regards - Eliot

Re: Why is taskset still not in util-linux?

[Marco Atzeri]

Am 19.03.2020 um 11:14 schrieb Eliot Moss:
> On 3/16/2020 7:34 PM, Mark Geisert wrote:
>  > Mark Geisert wrote:
>  >> Eliot Moss wrote:
>  >>>
>  >>> Dear cygwin-ers --
>  >>>
>  >>> Something I had asked about a while ago was the absence os taskset 
> in cygwin's
>  >>> util-linux.  At the time, it was pointed out that the necessary 
> get/set
>  >>> affinity library/system calls were not yet supported.  These were 
> added a
>  >>> while ago, so it would seem that taskset ought to work.  In fact, I 
> think
>  >>> someone got it going on their own.  Can we add it to util-linux now,
>  >>> officially?  I think this was intended but perhaps was overlooked or
>  >>> something.
>  >>
>  >> Report noted; thanks.  A solution is being worked.
>  >
>  > There's been no forward progress on this.  If you're comfortable 
> getting the util-linux source
>  > package through Cygwin setup*.exe, you can follow the steps shown in
>  > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to 
> build (with cygport) a local copy
>  > of util-linux that includes a taskset.exe you can move into 
> /usr/local/bin, for example.
>  >
>  > You might try that route if you're up for it.  Feel free to ask 
> questions here if you hit a snag.
>  > HTH,
> 
> Thank you, Mark.  I decided to give it a try and got some distance, but 
> hit a snag.
> 
> First, I had to change configure.ac to add control to disable ionice 
> (Cygwin
> does not support a required syscall) while still trying to build taskset.
> Previously taskset and ionice (and one other program) were controlled by 
> the
> single --enable-schedutils.
> 
> Now, including sched.h does not provide the prototypes for 
> sched_getaffinity,
> etc.  I found a previous post that suggests we need to do -D_GNU_SOURCE 
> for it
> to work.  I am not sure of the best place to stick that, but I will see 
> about
> maybe a one line patch to taskset.c or something.
> 
> Regards - Eliot

one brutal solution I recently used

         cygconf
         echo "defining _GNU_SOURCE on config.h"
         echo "#define _GNU_SOURCE 1" >> config.h
         cygmake

the patch approach is usually restricted to a portion
of the code or a general header.
May be there is already something like that in the code,
or you can add a similar stuff

  #if defined(__linux__) || defined(__CYGWIN__)
  #   ifndef _GNU_SOURCE
  #       define _GNU_SOURCE
  #   endif

Re: Why is taskset still not in util-linux?

[Mark Geisert]

Eliot Moss wrote:
> On 3/16/2020 7:34 PM, Mark Geisert wrote:
>  > Mark Geisert wrote:
>  >> Eliot Moss wrote:
>  >>>
>  >>> Dear cygwin-ers --
>  >>>
>  >>> Something I had asked about a while ago was the absence os taskset in cygwin's
>  >>> util-linux.  At the time, it was pointed out that the necessary get/set
>  >>> affinity library/system calls were not yet supported.  These were added a
>  >>> while ago, so it would seem that taskset ought to work.  In fact, I think
>  >>> someone got it going on their own.  Can we add it to util-linux now,
>  >>> officially?  I think this was intended but perhaps was overlooked or
>  >>> something.
>  >>
>  >> Report noted; thanks.  A solution is being worked.
>  >
>  > There's been no forward progress on this.  If you're comfortable getting the 
> util-linux source
>  > package through Cygwin setup*.exe, you can follow the steps shown in
>  > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build 
> (with cygport) a local copy
>  > of util-linux that includes a taskset.exe you can move into /usr/local/bin, 
> for example.
>  >
>  > You might try that route if you're up for it.  Feel free to ask questions 
> here if you hit a snag.
>  > HTH,
> 
> Thank you, Mark.  I decided to give it a try and got some distance, but hit a snag.
> 
> First, I had to change configure.ac to add control to disable ionice (Cygwin
> does not support a required syscall) while still trying to build taskset.
> Previously taskset and ionice (and one other program) were controlled by the
> single --enable-schedutils.
> 
> Now, including sched.h does not provide the prototypes for sched_getaffinity,
> etc.  I found a previous post that suggests we need to do -D_GNU_SOURCE for it
> to work.  I am not sure of the best place to stick that, but I will see about
> maybe a one line patch to taskset.c or something.

Rats.  Sorry you've hit some snags.  Are you compiling directly with 'make' or 
the preferred 'cygport util-linux.cygport build'?  With the latter I didn't need 
to make any changes to the source tree; all mods were accomplished with the new 
patch file and changes to util-linux.cygport itself.

..mark

Re: Why is taskset still not in util-linux?

[Mark Geisert]

Mark Geisert wrote:
> Eliot Moss wrote:
>> On 3/16/2020 7:34 PM, Mark Geisert wrote:
>>  > Mark Geisert wrote:
>>  >> Eliot Moss wrote:
>>  >>>
>>  >>> Dear cygwin-ers --
>>  >>>
>>  >>> Something I had asked about a while ago was the absence os taskset in 
>> cygwin's
>>  >>> util-linux.  At the time, it was pointed out that the necessary get/set
>>  >>> affinity library/system calls were not yet supported.  These were added a
>>  >>> while ago, so it would seem that taskset ought to work.  In fact, I think
>>  >>> someone got it going on their own.  Can we add it to util-linux now,
>>  >>> officially?  I think this was intended but perhaps was overlooked or
>>  >>> something.
>>  >>
>>  >> Report noted; thanks.  A solution is being worked.
>>  >
>>  > There's been no forward progress on this.  If you're comfortable getting 
>> the util-linux source
>>  > package through Cygwin setup*.exe, you can follow the steps shown in
>>  > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build 
>> (with cygport) a local copy
>>  > of util-linux that includes a taskset.exe you can move into /usr/local/bin, 
>> for example.
>>  >
>>  > You might try that route if you're up for it.  Feel free to ask questions 
>> here if you hit a snag.
>>  > HTH,
>>
>> Thank you, Mark.  I decided to give it a try and got some distance, but hit a 
>> snag.
>>
>> First, I had to change configure.ac to add control to disable ionice (Cygwin
>> does not support a required syscall) while still trying to build taskset.
>> Previously taskset and ionice (and one other program) were controlled by the
>> single --enable-schedutils.
>>
>> Now, including sched.h does not provide the prototypes for sched_getaffinity,
>> etc.  I found a previous post that suggests we need to do -D_GNU_SOURCE for it
>> to work.  I am not sure of the best place to stick that, but I will see about
>> maybe a one line patch to taskset.c or something.
> 
> Rats.  Sorry you've hit some snags.  Are you compiling directly with 'make' or 
> the preferred 'cygport util-linux.cygport build'?  With the latter I didn't need 
> to make any changes to the source tree; all mods were accomplished with the new 
> patch file and changes to util-linux.cygport itself.

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.

..mark

Re: Why is taskset still not in util-linux?

[Eliot Moss]

On 3/20/2020 1:54 AM, Mark Geisert wrote:
> Mark Geisert wrote:
>> Eliot Moss wrote:

>> Rats.  Sorry you've hit some snags.  Are you compiling directly with 'make' or the preferred 
>> 'cygport util-linux.cygport build'?  With the latter I didn't need to make any changes to the 
>> source tree; all mods were accomplished with the new patch file and changes to util-linux.cygport 
>> itself.
> 
> 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.

What an amusing hack!  I especially like the sensibility of 42!  :-)

I will try this.  When I built it last night, I got a successful compile, but it didn't do anything.
For example, taskset 1 ls did not output _anything_ -- no error message and no ls output :-( ...

It will be the weekend here in Australia (I'm visiting, and wondering about exactly how and when I
will get home) so maybe I'll play with it some more on Saturday ...

Regards - Eliot

Re: Why is taskset still not in util-linux?

[Yaakov Selkowitz]

On Thu, 2020-03-19 at 22:54 -0700, Mark Geisert wrote:
> Mark Geisert wrote:
> > Eliot Moss wrote:
> > > On 3/16/2020 7:34 PM, Mark Geisert wrote:
> > >  > Mark Geisert wrote:
> > >  >> Eliot Moss wrote:
> > >  >>>
> > >  >>> Dear cygwin-ers --
> > >  >>>
> > >  >>> Something I had asked about a while ago was the absence os taskset in 
> > > cygwin's
> > >  >>> util-linux.  At the time, it was pointed out that the necessary get/set
> > >  >>> affinity library/system calls were not yet supported.  These were added a
> > >  >>> while ago, so it would seem that taskset ought to work.  In fact, I think
> > >  >>> someone got it going on their own.  Can we add it to util-linux now,
> > >  >>> officially?  I think this was intended but perhaps was overlooked or
> > >  >>> something.
> > >  >>
> > >  >> Report noted; thanks.  A solution is being worked.
> > >  >
> > >  > There's been no forward progress on this.  If you're comfortable getting 
> > > the util-linux source
> > >  > package through Cygwin setup*.exe, you can follow the steps shown in
> > >  > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build 
> > > (with cygport) a local copy
> > >  > of util-linux that includes a taskset.exe you can move into /usr/local/bin, 
> > > for example.
> > >  >
> > >  > You might try that route if you're up for it.  Feel free to ask questions 
> > > here if you hit a snag.
> > >  > HTH,
> > > 
> > > Thank you, Mark.  I decided to give it a try and got some distance, but hit a 
> > > snag.
> > > 
> > > First, I had to change configure.ac to add control to disable ionice (Cygwin
> > > does not support a required syscall) while still trying to build taskset.
> > > Previously taskset and ionice (and one other program) were controlled by the
> > > single --enable-schedutils.
> > > 
> > > Now, including sched.h does not provide the prototypes for sched_getaffinity,
> > > etc.  I found a previous post that suggests we need to do -D_GNU_SOURCE for it
> > > to work.  I am not sure of the best place to stick that, but I will see about
> > > maybe a one line patch to taskset.c or something.
> > 
> > Rats.  Sorry you've hit some snags.  Are you compiling directly with 'make' or 
> > the preferred 'cygport util-linux.cygport build'?  With the latter I didn't need 
> > to make any changes to the source tree; all mods were accomplished with the new 
> > patch file and changes to util-linux.cygport itself.
> 
> 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.

Cygwin doesn't support syscalls.  I'd be very wary of any code which is
conditional on any #ifdef SYS_*.

--
Yaakov

Re: Why is taskset still not in util-linux?

[Andrey Repin]

Greetings, Eliot Moss!

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

> What an amusing hack!  I especially like the sensibility of 42!  :-)

Because that's THE ANSWER!

> I will try this.  When I built it last night, I got a successful compile,
> but it didn't do anything.  For example, taskset 1 ls did not output
> _anything_ -- no error message and no ls output :-( ...

> It will be the weekend here in Australia (I'm visiting, and wondering about
> exactly how and when I will get home) so maybe I'll play with it some more
> on Saturday ...


-- 
With best regards,
Andrey Repin
Saturday, March 21, 2020 0:41:58

Sorry for my terrible english...

Re: Why is taskset still not in util-linux?

[Eliot Moss]

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.

Regards - Eliot

Re: Why is taskset still not in util-linux?

[Eliot Moss]

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!

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.

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.

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.

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

Your thoughts about not being able to run the installed version?

Eliot

Re: Why is taskset still not in util-linux?

[Mark Geisert]

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

Re: Why is taskset still not in util-linux?

[Mark Geisert]

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

Re: Why is taskset still not in util-linux?

[Eliot Moss]

Dear Mark - I am confused by how your build goes through when configure
detects the ionice does not have the ioprio_set/get calls that it needs.  In my
case configure stops at that point.  That was why I made a patch to
configure.ac so that cygport could explicitly exclude ionice.  At the moment,
I am seeing what happens if I add more "fake" syscalls to syscall.h for those
two calls.  The configure goes through (as expected), but of course ionice
fails to link (no 'syscall" function).

If I revert to having only SYS_sched_getaffinity defined, configure stops
with:

checking for syscall ioprio_set... no
configure: WARNING: Unable to detect syscall ioprio_set.
configure: error: ionice selected but ioprio_set syscall not found
*** ERROR: configure failed

That why I think I/we need some kind of patch to configure.ac.  How does
your build manage to continue?

I am working from the Cygwin util-linux-2.33.1-1 source package.  Is that the
correct one?  Also, I am in the x86-64 world for all this.

Eliot

Re: Why is taskset still not in util-linux?

[Eliot Moss]

So here's a thing, though I don't understand it:

In addition the build/taskset.exe, there's a build/.libs/taskset.exe.
If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset
works.  In fact, it seems that the version in .libs is the "real" program
and /usr/bin/taskset is some kind of trampoline (?) to it?

In fact, a stripped version of build/.libs/taskset installed in /usr/bin
works just fine.  There must be some kind of build and install convention
going on that I am not familiar with.  (I'm not familiar with a lot of
these build processes, actually.)

Best - Eliot

Re: Why is taskset still not in util-linux?

[Marco Atzeri]

Am 21.03.2020 um 12:07 schrieb Eliot Moss:
> So here's a thing, though I don't understand it:
> 
> In addition the build/taskset.exe, there's a build/.libs/taskset.exe.

that is usually the unstripped version

> If I install the latter in /usr/bin/.libs/taskset.exe, then 
> /usr/bin/taskset
> works.  In fact, it seems that the version in .libs is the "real" program
> and /usr/bin/taskset is some kind of trampoline (?) to it?

it is the libtool wrapper, infact it is linked only to cygwin1.dll


$ objdump -x .libs/gprof.exe | grep "DLL Name"
         DLL Name: cygwin1.dll
         DLL Name: cygintl-8.dll
         DLL Name: KERNEL32.dll

$ objdump -x gprof.exe | grep "DLL Name"
         DLL Name: cygwin1.dll
         DLL Name: KERNEL32.dll


$ strings gprof.exe | grep ".libs"
./.libs/lt-gprof.c
# gprof - temporary wrapper script for .libs/gprof
...

> 
> In fact, a stripped version of build/.libs/taskset installed in /usr/bin
> works just fine.  There must be some kind of build and install convention
> going on that I am not familiar with.  (I'm not familiar with a lot of
> these build processes, actually.)
> 
> Best - Eliot

I also forget the details from time to time...

Marco

Re: Why is taskset still not in util-linux?

[Roumen Petrov]

Eliot Moss wrote:
> So here's a thing, though I don't understand it:
>
> In addition the build/taskset.exe, there's a build/.libs/taskset.exe.
> If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset
> works.  In fact, it seems that the version in .libs is the "real" program
> and /usr/bin/taskset is some kind of trampoline (?) to it?
Libtool wrapper is shell script on Unix/Linux and executable on Microsoft Windows OS. Goal of "wrapper" is to prepare environment in the way that allows to run real executable without installation.
Project that creates just one executable is not the beast sample but think for a library project and a bundle of tests (executable). All tests must load library from build tree.


>
> In fact, a stripped version of build/.libs/taskset installed in /usr/bin
> works just fine.  There must be some kind of build and install convention
> going on that I am not familiar with.  (I'm not familiar with a lot of
> these build processes, actually.)
I think that in some cases this executable has to be relinked. Definitely not on Microsoft Windows OS. So on cygwin it is "final" executable.


>
> Best - Eliot

Regards,
Roumen

Re: Why is taskset still not in util-linux?

[Brian Inglis]

On 2020-03-21 02:18, Mark Geisert wrote:
> 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.
>> Once I did that properly, it built without commenting out that test. Yay!

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

Anyone know if this feature support or what feature support will get top P/last
used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently
assigned CPU showing actual CPUs rather than 0/zero?

Anyone know if or where or how this info is available on Windows or a link to
it? I've looked at Google and SO results and nothing useful is apparent.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: Why is taskset still not in util-linux?

[Eliot Moss]

On 3/21/2020 10:26 AM, Roumen Petrov wrote:
 > Eliot Moss wrote:
 >> So here's a thing, though I don't understand it:
 >>
 >> In addition the build/taskset.exe, there's a build/.libs/taskset.exe.
 >> If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset
 >> works.  In fact, it seems that the version in .libs is the "real" program
 >> and /usr/bin/taskset is some kind of trampoline (?) to it?
 > Libtool wrapper is shell script on Unix/Linux and executable on Microsoft Windows OS. Goal of
 > "wrapper" is to prepare environment in the way that allows to run real executable without 
installation.
 > Project that creates just one executable is not the beast sample but think for a library project and
 > a bundle of tests (executable). All tests must load library from build tree.
 >
 >
 >>
 >> In fact, a stripped version of build/.libs/taskset installed in /usr/bin
 >> works just fine.  There must be some kind of build and install convention
 >> going on that I am not familiar with.  (I'm not familiar with a lot of
 >> these build processes, actually.)
 > I think that in some cases this executable has to be relinked. Definitely not on Microsoft Windows
 > OS. So on cygwin it is "final" executable.

Thanks - I start to get the picture.  What is odd is that 'cygport install'
puts the _wrapper_ into /usr/bin rather than the executable, and does not
install the exectable.  The wrapper just silently fails.  Now maybe if I built
the package (as if I were the package maintainer) and installed that with
cygwin's setup, I would get the right thing - not sure (and not 100% sure how
to do that).

Cheers - EM

Re: Why is taskset still not in util-linux?

[Eliot Moss]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

Well, I had _thought_ I had done 'cygport install' and run the installed
version, but I seem to have been wrong.  I seem to have manually over-written
the proper (stripped) binary with the wrapper!

Anyway, I've got the whole thing working and offer the attached patches for
"thoughtful consideration".  I have done away with the need to create an empty
or fake /usr/local/include/sys/syscall.h and changed the source of the
relevant programs to conditional #include <sys/syscall.h> on #indef
__CYGWIN__, which sruck me as more legitimate (the file in questions is
patched anyway).  And I improved configure.ac so that the programs controlled
by --enable-schedutils are more independent and can fail individually without
failing the build.  Part of that was subtituting, as a patch to configure.ac,
a check for the sched_getaffinity and sched_setaffinity calls in place of the
check for the corresponding syscall.  The whole builds and installs.  I can
provide the packaged up version (I assume that is the 'dist' hierarchy) if
that would be helpful.

Regards - Eliot

[-- Attachment #2: util-linux.cygport --]
[-- Type: text/plain, Size: 4179 bytes --]

NAME="util-linux"
VERSION=2.33.1
RELEASE=1
CATEGORY="Base"
SUMMARY="Collection of basic system utilities"
HOMEPAGE="https://github.com/karelzak/util-linux/"
SRC_URI="https://mirrors.edge.kernel.org/pub/linux/utils/${NAME}/v${PV_MAJ_MIN}/${NAME}-${VERSION}.tar.xz"
PATCH_URI="
	2.24.2-libintl.patch
	2.25.1-cygwin-include.patch
	2.24.2-agetty.patch
	2.24.2-libblkid-topology.patch
	2.32.1-testsuite.patch
	2.33.1-cygwin-cpuset.patch
	2.33.1-cygwin-cpuset.patch2
	2.33.1-cygwin-ionice.patch
	2.33.1-cygwin-taskset.patch
"

PKG_NAMES="${NAME} libblkid1 libblkid-devel libfdisk1 libfdisk-devel
	   libsmartcols1 libsmartcols-devel libuuid1 libuuid-devel uuidd"
util_linux_CONTENTS="
	--exclude=*.dll --exclude=uuidd*
	bin/*
	sbin/*
	usr/bin/*
	usr/share/bash-completion/
	usr/share/doc/${NAME}
	usr/share/locale/*/*/util-linux.mo
	usr/share/man/man[158]/*
"
libblkid1_CATEGORY="Libs"
libblkid1_SUMMARY="Block device ID library (runtime)"
libblkid1_CONTENTS="usr/bin/cygblkid-1.dll"
libblkid_devel_CATEGORY="Libs"
libblkid_devel_SUMMARY="Block device ID library (development)"
libblkid_devel_CONTENTS="
	usr/include/blkid/
	usr/lib/libblkid.*
	usr/lib/pkgconfig/blkid.pc
	usr/share/man/man3/*blkid*
"
libfdisk1_CATEGORY="Libs"
libfdisk1_SUMMARY="Disk partition table manipulation library (runtime)"
libfdisk1_CONTENTS="usr/bin/cygfdisk-1.dll"
libfdisk_devel_CATEGORY="Libs"
libfdisk_devel_SUMMARY="Disk partition table manipulation library (development)"
libfdisk_devel_CONTENTS="
	usr/include/libfdisk/
	usr/lib/libfdisk.*
	usr/lib/pkgconfig/fdisk.pc
"
libsmartcols1_CATEGORY="Libs"
libsmartcols1_SUMMARY="Tabular data formatting library (runtime)"
libsmartcols1_DESCRIPTION="The libsmartcols library is used for smart
adaptive formatting of tabular data."
libsmartcols1_CONTENTS="usr/bin/cygsmartcols-1.dll"
libsmartcols_devel_CATEGORY="Libs"
libsmartcols_devel_SUMMARY="Tabular data formatting library (development)"
libsmartcols_devel_DESCRIPTION=${libsmartcols1_DESCRIPTION}
libsmartcols_devel_CONTENTS="
	usr/include/libsmartcols/
	usr/lib/libsmartcols.*
	usr/lib/pkgconfig/smartcols.pc
"
libuuid1_CATEGORY="Libs"
libuuid1_SUMMARY="Universally Unique ID library (runtime)"
libuuid1_CONTENTS="usr/bin/cyguuid-1.dll"
libuuid_devel_CATEGORY="Libs"
libuuid_devel_SUMMARY="Universally Unique ID library (development)"
libuuid_devel_CONTENTS="
	usr/include/uuid/
	usr/lib/libuuid.*
	usr/lib/pkgconfig/uuid.pc
	usr/share/man/man3/*uuid*
"
uuidd_CATEGORY="System"
uuidd_SUMMARY="UUID daemon"
uuidd_CONTENTS="
	usr/sbin/uuidd.exe
	usr/share/bash-completion/completions/uuidd
	usr/share/man/man8/uuidd.8*
	var/lib/libuuid/
	var/run/uuidd/
"

BUILD_REQUIRES="
	bison
	gettext-devel
	libcrypt-devel
	libncurses-devel
	libreadline-devel
	zlib-devel
"

CPPFLAGS+=" -D__USE_LINUX_IOCTL_DEFS"

# fsck: e2fsprogs
# ipcrm, ipcs: ipc-utils
# kill, mount: cygwin
# login: login
# su: coreutils
# last, mesg, mountpoint, utmpdump, wall: sysvinit
# others are linux-specific or obsolete
CYGCONF_ARGS="
  --runstatedir=/var/run
  --enable-libuuid
  --enable-libuuid-force-uuidd
  --enable-libblkid
  --enable-libfdisk
  --disable-libmount
  --disable-mount
  --disable-losetup
  --disable-fsck
  --disable-partx
  --enable-uuidd
  --disable-mountpoint
  --disable-fallocate
  --disable-unshare
  --disable-nsenter
  --disable-setpriv
  --disable-eject
  --enable-agetty
  --enable-cramfs
  --enable-bfs
  --disable-fdformat
  --disable-hwclock
  --disable-wdctl
  --disable-switch_root
  --disable-pivot_root
  --disable-ipcrm
  --disable-ipcs
  --disable-tunelp
  --disable-kill
  --disable-last
  --disable-lslogins
  --disable-utmpdump
  --disable-line
  --disable-mesg
  --disable-raw
  --enable-rename
  --disable-vipw
  --disable-newgrp
  --disable-chfn-chsh
  --disable-login
  --enable-nologin
  --disable-sulogin
  --disable-su
  --disable-runuser
  --enable-ul
  --enable-more
  --enable-pg
  --disable-setterm
  --enable-schedutils
  --disable-wall
  --disable-write
  --disable-use-tty-group
  --disable-makeinstall-chown
  --disable-makeinstall-setuid
  SOLIB_LDFLAGS=-no-undefined
"

# prevents bogus .so symlinks
MAKEOPTS+=" libdir=/usr/lib"

KEEPDIRS="/var/lib/libuuid /var/run/uuidd"

[-- Attachment #3: 2.33.1-cygwin-cpuset.patch2 --]
[-- Type: text/plain, Size: 326 bytes --]

--- origsrc/util-linux-2.33.1/lib/cpuset.c	2020-03-21 20:48:54.978830500 -0400
+++ src/util-linux-2.33.1/lib/cpuset.c	2020-03-21 21:21:56.238472500 -0400
@@ -20,7 +20,9 @@
 #include <errno.h>
 #include <string.h>
 #include <ctype.h>
+#ifndef __CYGWIN__
 #include <sys/syscall.h>
+#endif
 
 #include "cpuset.h"
 #include "c.h"

[-- Attachment #4: 2.33.1-cygwin-ionice.patch --]
[-- Type: text/plain, Size: 581 bytes --]

--- origsrc/util-linux-2.33.1/configure.ac	2020-03-21 20:19:20.952384000 -0400
+++ src/util-linux-2.33.1/configure.ac	2020-03-21 20:42:40.640966200 -0400
@@ -2054,8 +2054,13 @@
 )
 
 
-UL_ENABLE_ALIAS([ionice], [schedutils])
-UL_BUILD_INIT([ionice])
+AC_ARG_ENABLE([ionice],
+  AS_HELP_STRING([--disable-ionice], [disable ionice even if schedutils is enabled]),
+  [], [UL_DEFAULT_ENABLE([ionice], [check])]
+)
+
+UL_BUILD_INIT([ionice], [check])
+UL_REQUIRES_BUILD([ionice], [schedutils])
 UL_REQUIRES_SYSCALL_CHECK([ionice],
 	[UL_CHECK_SYSCALL([ioprio_set],
 	  [alpha],	[442],

[-- Attachment #5: 2.33.1-cygwin-taskset.patch --]
[-- Type: text/plain, Size: 1036 bytes --]

--- origsrc/util-linux-2.33.1/configure.ac	2020-03-21 23:12:49.481503500 -0400
+++ src/util-linux-2.33.1/configure.ac	2020-03-21 23:17:20.565468100 -0400
@@ -2052,6 +2052,7 @@
   AS_HELP_STRING([--disable-schedutils], [do not build chrt, ionice, taskset]),
   [], [UL_DEFAULT_ENABLE([schedutils], [check])]
 )
+UL_BUILD_INIT([schedutils])
 
 
 UL_ENABLE_ALIAS([ionice], [schedutils])
@@ -2083,12 +2084,11 @@
 AM_CONDITIONAL([BUILD_IONICE], [test "x$build_ionice" = xyes])
 
 
-UL_ENABLE_ALIAS([taskset], [schedutils])
-UL_BUILD_INIT([taskset])
+UL_BUILD_INIT([taskset], [check])
+UL_REQUIRES_BUILD([taskset], [schedutils])
 UL_REQUIRES_HAVE([taskset], [cpu_set_t], [cpu_set_t type])
-UL_REQUIRES_SYSCALL_CHECK([taskset],
-	[UL_CHECK_SYSCALL([sched_getaffinity])],
-	[sched_getaffinity])
+AC_CHECK_FUNCS([sched_getaffinity sched_setaffinity], [have_schedaffinity=yes],[have_schedaffinity=no])
+UL_REQUIRES_HAVE([taskset], [schedaffinity], [sched affinity functions])
 AM_CONDITIONAL([BUILD_TASKSET], [test "x$build_taskset" = xyes])
 
 

Re: Why is taskset still not in util-linux?

[Eliot Moss]

PS - The same patches work fine for a 32-bit build (I just test it).  Again, I
can supply the package files if desired.

Regards - EM

Re: Why is taskset still not in util-linux?

[Yaakov Selkowitz]

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

Re: Why is taskset still not in util-linux?

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

On Mar 21 10:41, Brian Inglis wrote:
> On 2020-03-21 02:18, Mark Geisert wrote:
> > 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.
> >> Once I did that properly, it built without commenting out that test. Yay!
> 
> > 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.
> 
> Anyone know if this feature support or what feature support will get top P/last
> used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently
> assigned CPU showing actual CPUs rather than 0/zero?
> 
> Anyone know if or where or how this info is available on Windows or a link to
> it? I've looked at Google and SO results and nothing useful is apparent.

Can't we just fake the calls?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Why is taskset still not in util-linux?

[Mark Geisert]

Corinna Vinschen wrote:
> On Mar 21 10:41, Brian Inglis wrote:
>> On 2020-03-21 02:18, Mark Geisert wrote:
>>> 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.
>>>> Once I did that properly, it built without commenting out that test. Yay!
>>
>>> 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.
>>
>> Anyone know if this feature support or what feature support will get top P/last
>> used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently
>> assigned CPU showing actual CPUs rather than 0/zero?
>>
>> Anyone know if or where or how this info is available on Windows or a link to
>> it? I've looked at Google and SO results and nothing useful is apparent.
> 
> Can't we just fake the calls?

Brian is asking for a way to watch processes globally, as they are scheduled 
back and forth on the available cpus.  I was a bit sloppy in my wording above; 
what Process Lasso displays is the changing process affinity mask for a process 
I wrote to do just that.  I don't know of a way to ask Windows which cpu a 
process is currently scheduled onto.

..mark

Re: Why is taskset still not in util-linux?

[Brian Inglis]

On 2020-03-23 03:42, Mark Geisert wrote:
> Corinna Vinschen wrote:
>> On Mar 21 10:41, Brian Inglis wrote:
>>> On 2020-03-21 02:18, Mark Geisert wrote:
>>>> 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.
>>>>> Once I did that properly, it built without commenting out that test. Yay!
>>>
>>>> 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.
>>>
>>> Anyone know if this feature support or what feature support will get top P/last
>>> used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently
>>> assigned CPU showing actual CPUs rather than 0/zero?
>>>
>>> Anyone know if or where or how this info is available on Windows or a link to
>>> it? I've looked at Google and SO results and nothing useful is apparent.
>>
>> Can't we just fake the calls?

The results are currently faked to CPU # 0.

> Brian is asking for a way to watch processes globally, as they are scheduled
> back and forth on the available cpus.  I was a bit sloppy in my wording above;
> what Process Lasso displays is the changing process affinity mask for a process
> I wrote to do just that.  I don't know of a way to ask Windows which cpu a
> process is currently scheduled onto.

You can also get and set affinity in Task Manager, and also ideal CPU info using
SysInternals Process Explorer, or PowerShell, which I use to launch Windows ntpd
at max realtime priority on CPU `nproc` - 1, as CMD arithmetic was nonexistent
or obscure years ago. I could probably redo that with CMD start.

Only documented CPU # call I could find was GetCurrentProcessorNumber (-Ex also
returns processor group) which tells the current thread where it's executing,
not the last or current CPU # assigned or used for other process threads.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: Why is taskset still not in util-linux?

[Mark Geisert]

Eliot Moss wrote:
> Well, I had _thought_ I had done 'cygport install' and run the installed
> version, but I seem to have been wrong.  I seem to have manually over-written
> the proper (stripped) binary with the wrapper!
> 
> Anyway, I've got the whole thing working and offer the attached patches for
> "thoughtful consideration".  I have done away with the need to create an empty
> or fake /usr/local/include/sys/syscall.h and changed the source of the
> relevant programs to conditional #include <sys/syscall.h> on #indef
> __CYGWIN__, which sruck me as more legitimate (the file in questions is
> patched anyway).  And I improved configure.ac so that the programs controlled
> by --enable-schedutils are more independent and can fail individually without
> failing the build.  Part of that was subtituting, as a patch to configure.ac,
> a check for the sched_getaffinity and sched_setaffinity calls in place of the
> check for the corresponding syscall.  The whole builds and installs.  I can
> provide the packaged up version (I assume that is the 'dist' hierarchy) if
> that would be helpful.

Thanks very much for working on all this and contributing it.  I will build and 
test as soon as I can.  I need to research the packaging steps because I intend 
to ITA this package.  I do also want to take another look at the other programs 
built as part of --enable-schedutils; they might (or might not) build cleanly 
but AFAIK there's no support within Cygwin and/or Windows for what they can do 
on Linux.

Thanks again,

..mark

Re: Why is taskset still not in util-linux?

[Eliot Moss]

On 3/24/2020 4:09 AM, Mark Geisert wrote:
> Eliot Moss wrote:
>> Well, I had _thought_ I had done 'cygport install' and run the installed
>> version, but I seem to have been wrong.  I seem to have manually over-written
>> the proper (stripped) binary with the wrapper!
>>
>> Anyway, I've got the whole thing working and offer the attached patches for
>> "thoughtful consideration".  I have done away with the need to create an empty
>> or fake /usr/local/include/sys/syscall.h and changed the source of the
>> relevant programs to conditional #include <sys/syscall.h> on #indef
>> __CYGWIN__, which sruck me as more legitimate (the file in questions is
>> patched anyway).  And I improved configure.ac so that the programs controlled
>> by --enable-schedutils are more independent and can fail individually without
>> failing the build.  Part of that was subtituting, as a patch to configure.ac,
>> a check for the sched_getaffinity and sched_setaffinity calls in place of the
>> check for the corresponding syscall.  The whole builds and installs.  I can
>> provide the packaged up version (I assume that is the 'dist' hierarchy) if
>> that would be helpful.
> 
> Thanks very much for working on all this and contributing it.  I will build and test as soon as I 
> can.  I need to research the packaging steps because I intend to ITA this package.  I do also want 
> to take another look at the other programs built as part of --enable-schedutils; they might (or 
> might not) build cleanly but AFAIK there's no support within Cygwin and/or Windows for what they can 
> do on Linux.

Agreed - glad to help!   Eliot