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

On Fri, 2019-06-28 at 03:17 -0700, Mark Geisert wrote:
> 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<[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.
> 
> 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.

We shouldn't be do things half-way.  taskset may not require it, but
any use of CPU sets could very well expect this to be present:

http://man7.org/linux/man-pages/man3/CPU_SET.3.html

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.