Re: Cygwin: Implement sched_[gs]etaffinity() commit breaks RTEMS port
Mark Geisert <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
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. 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