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

[Mark Geisert]

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.

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?

Once I understand that, I can make the changes in my local build and make 
sure I can still build both Cygwin and util-linux with the changes.
Thanks much,

..mark