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.