This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Cygwin: Implement sched_[gs]etaffinity() commit breaks RTEMS port
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<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.
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.
Let me know what you think when you have a chance.
Thanks all,
..mark