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

Sebastian Huber <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
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<[email protected]>
>>>>>>> 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  : [email protected]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.