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

[Sebastian Huber]

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.

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

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.