This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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. Thanks for looking into this. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
signature.asc
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |