Cygwin: Implement sched_[gs]etaffinity() commit breaks RTEMS port

[Mark Geisert]

On Fri, 28 Jun 2019, Sebastian Huber wrote:
> On 28/06/2019 10:48, Mark Geisert wrote:
>> On Thu, 27 Jun 2019, Corinna Vinschen wrote:
>>> On Jun 27 08:28, Sebastian Huber wrote:
>>>> On 26/06/2019 15:12, Corinna Vinschen wrote:
>>>>> On Jun 26 13:05, Sebastian Huber wrote:
>>>>>> On 26/06/2019 11:37, Corinna Vinschen wrote:
>>>>>>> On Jun 26 10:24, Sebastian Huber wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> the following commit:
>>>>>>>> 
>>>>>>>> commit 641ecb07533e85211b6abce334c85967f3f90209
>>>>>>>> Author: Mark Geisert<mark@maxrnd.com>
>>>>>>>> Date:   Sun Jun 23 14:51:06 2019 -0700
>>>>>>>> 
>>>>>>>>       Cygwin: Implement sched_[gs]etaffinity()
>>>>>>>> [...]
>>>>>>>> breaks the RTEMS port:
>>>>>>>> [...]
>>>>>>> Looks like Cygwin has to define its own sys/cpuset.h included via
>>>>>>> sys/_pthreadtypes.h.
>>>>>> 
>>>>>> Yes, something like this. The RTEMS <sys/cpuset.h> is based on the 
>>>>>> FreeBSD
>>>>>> implementation and should be compatible to the Linux API. Maybe it can 
>>>>>> move
>>>>>> out of the RTEMS area into the global Newlib area.
>>>>> 
>>>>> I'm not so sure, given the different names of macros and types used
>>>>> inside cpu_set_t.  The new functions inside Cygwin rely on that.
>>>> 
>>>> How do you implement this API in Cygwin:
>>>> 
>>>> http://man7.org/linux/man-pages/man3/CPU_SET.3.html
>>>> 
>>>> I think the RTEMS <sys/cpuset.h> implementation should cover it.
>>> 
>>> AFAICS we don't.
>>> 
>>> Mark, do you see much of a problem to rearrange your new
>>> sched_[gs]etaffinity code to use the RTEMS sys/cpuset.h file?
>>> 
>>> We can define our own sys/_cpuset.h, or use the RTEMS file as well.
>> 
>> Hi folks,
>> I was trying to minimize update scope while implementing the affinity calls 
>> from Linux for Cygwin.  I noticed that taskset(1), from the util-linux 
>> package, supplies its own CPU_SET implementation (copied from glibc) so I 
>> decided to not supply one for Cygwin but let taskset use its own.  I felt 
>> we could add CPU_SET to Cygwin when necessary, later.
>> 
>> The macro #defines I added to sched.h are those needed by Linux CPU_SET 
>> regardless of how it gets defined.  I worry about trying to use a FreeBSD 
>> based CPU_SET -- just from unfamiliarity.
>
> The RTEMS <sys/cpuset.h> implements the Linux and FreeBSD APIs. In case of 
> conflict (and there are conflicts, the libc developers should talk more with 
> each other) we choose the Linux variant.

O.K. Thank you for the background.

>> 
>> Corinna, I see how your workaround patch moves my macros to Cygwin's 
>> sys/cpuset.h.  That seems fine to me.
>> 
>> I don't see how the include linkage through _pthreadtypes.h works though. 
>> How does a user app including <sched.h> get <sys/cpuset.h> pulled in?
>
> It is included via <sys/types.h> -> <sys/_pthreadtypes.h> -> <sys/cpuset.h>.

Great!  Thank you Sebastian.

Corinna, I'm able to build Cygwin 64- and 32-bit with your updates, and to 
build util-linux as well.  I have a resulting working taskset executable.

It was not necessary to implement the CPU_SET functionality via any of the 
possible ways because taskset supplies its own if it can't find one.

We can call it a day, with review and release of the current patch state.
If you think it's worthwhile to implement CPU_SET on Cygwin now, rather 
than later, I can look into it but it's not strictly necessary at this 
time.

Let me know what you think when you have a chance.
Thanks all,

..mark