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

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Huber-4
Hello,

the following commit:

commit 641ecb07533e85211b6abce334c85967f3f90209
Author: Mark Geisert <[hidden email]>
Date:   Sun Jun 23 14:51:06 2019 -0700

     Cygwin: Implement sched_[gs]etaffinity()

     This patch set implements the Linux syscalls sched_getaffinity,
     sched_setaffinity, pthread_getaffinity_np, and pthread_setaffinity_np.
     Linux has a straightforward view of the cpu sets used in affinity
masks.
     They are simply long (1024-bit) bit masks.  This code emulates that
view
     while internally dealing with Windows' distribution of available
CPUs among
     processor groups.

breaks the RTEMS port:

In file included from
/usr/home/user/rtems-source-builder/rtems/build/aarch64-rtems6-gcc-55a600a6ce9-newlib-09e2ec87e-x86_64-freebsd12.0-1/gnu-mirror-gcc-55a600a6ce9/newlib/libc/include/pthread.h:31,
                  from ./gthr-default.h:31,
                  from
../../../gnu-mirror-gcc-55a600a6ce9/libgcc/gthr.h:148,
                  from
../../../gnu-mirror-gcc-55a600a6ce9/libgcc/emutls.c:31:
/usr/home/user/rtems-source-builder/rtems/build/aarch64-rtems6-gcc-55a600a6ce9-newlib-09e2ec87e-x86_64-freebsd12.0-1/gnu-mirror-gcc-55a600a6ce9/newlib/libc/include/sched.h:112:3:
error: conflicting types for 'cpu_set_t'
   112 | } cpu_set_t;
       |   ^~~~~~~~~
../../../gnu-mirror-gcc-55a600a6ce9/libgcc/../newlib/libc/sys/rtems/include/sys/cpuset.h:67:18:
note: previous declaration of 'cpu_set_t' was here
    67 | typedef cpuset_t cpu_set_t;
       |                  ^~~~~~~~~


--
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  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen
On Jun 26 10:24, Sebastian Huber wrote:

> Hello,
>
> the following commit:
>
> commit 641ecb07533e85211b6abce334c85967f3f90209
> Author: Mark Geisert <[hidden email]>
> Date:   Sun Jun 23 14:51:06 2019 -0700
>
>     Cygwin: Implement sched_[gs]etaffinity()
>
>     This patch set implements the Linux syscalls sched_getaffinity,
>     sched_setaffinity, pthread_getaffinity_np, and pthread_setaffinity_np.
>     Linux has a straightforward view of the cpu sets used in affinity masks.
>     They are simply long (1024-bit) bit masks.  This code emulates that view
>     while internally dealing with Windows' distribution of available CPUs
> among
>     processor groups.
>
> breaks the RTEMS port:
>
> In file included from /usr/home/user/rtems-source-builder/rtems/build/aarch64-rtems6-gcc-55a600a6ce9-newlib-09e2ec87e-x86_64-freebsd12.0-1/gnu-mirror-gcc-55a600a6ce9/newlib/libc/include/pthread.h:31,
>                  from ./gthr-default.h:31,
>                  from ../../../gnu-mirror-gcc-55a600a6ce9/libgcc/gthr.h:148,
>                  from
> ../../../gnu-mirror-gcc-55a600a6ce9/libgcc/emutls.c:31:
> /usr/home/user/rtems-source-builder/rtems/build/aarch64-rtems6-gcc-55a600a6ce9-newlib-09e2ec87e-x86_64-freebsd12.0-1/gnu-mirror-gcc-55a600a6ce9/newlib/libc/include/sched.h:112:3:
> error: conflicting types for 'cpu_set_t'
>   112 | } cpu_set_t;
>       |   ^~~~~~~~~
> ../../../gnu-mirror-gcc-55a600a6ce9/libgcc/../newlib/libc/sys/rtems/include/sys/cpuset.h:67:18:
> note: previous declaration of 'cpu_set_t' was here
>    67 | typedef cpuset_t cpu_set_t;
>       |                  ^~~~~~~~~
Looks like Cygwin has to define its own sys/cpuset.h included via
sys/_pthreadtypes.h.


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Huber-4
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<[hidden email]>
>> Date:   Sun Jun 23 14:51:06 2019 -0700
>>
>>      Cygwin: Implement sched_[gs]etaffinity()
>>
>>      This patch set implements the Linux syscalls sched_getaffinity,
>>      sched_setaffinity, pthread_getaffinity_np, and pthread_setaffinity_np.
>>      Linux has a straightforward view of the cpu sets used in affinity masks.
>>      They are simply long (1024-bit) bit masks.  This code emulates that view
>>      while internally dealing with Windows' distribution of available CPUs
>> among
>>      processor groups.
>>
>> breaks the RTEMS port:
>>
>> In file included from /usr/home/user/rtems-source-builder/rtems/build/aarch64-rtems6-gcc-55a600a6ce9-newlib-09e2ec87e-x86_64-freebsd12.0-1/gnu-mirror-gcc-55a600a6ce9/newlib/libc/include/pthread.h:31,
>>                   from ./gthr-default.h:31,
>>                   from ../../../gnu-mirror-gcc-55a600a6ce9/libgcc/gthr.h:148,
>>                   from
>> ../../../gnu-mirror-gcc-55a600a6ce9/libgcc/emutls.c:31:
>> /usr/home/user/rtems-source-builder/rtems/build/aarch64-rtems6-gcc-55a600a6ce9-newlib-09e2ec87e-x86_64-freebsd12.0-1/gnu-mirror-gcc-55a600a6ce9/newlib/libc/include/sched.h:112:3:
>> error: conflicting types for 'cpu_set_t'
>>    112 | } cpu_set_t;
>>        |   ^~~~~~~~~
>> ../../../gnu-mirror-gcc-55a600a6ce9/libgcc/../newlib/libc/sys/rtems/include/sys/cpuset.h:67:18:
>> note: previous declaration of 'cpu_set_t' was here
>>     67 | typedef cpuset_t cpu_set_t;
>>        |                  ^~~~~~~~~
> 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.

--
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  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen
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<[hidden email]>
> > > 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.

I prep'ed a patch to move the Cygwin-specific definitions out of the
way, can you please test it on RTEMS?  It's attached to this mail.


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

0001-sched-Move-Cygwin-cpuset-definitions-into-Cygwin-spe.patch (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Huber-4
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<[hidden email]>
>>>> 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.

>
> I prep'ed a patch to move the Cygwin-specific definitions out of the
> way, can you please test it on RTEMS?  It's attached to this mail.

Thanks, this fixes the build problem for RTEMS.

--
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  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen
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<[hidden email]>
> > > > > 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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mark Geisert
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<[hidden email]>
>>>>>> 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
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Huber-4
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<[hidden email]>
>>>>>>> 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  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Reply | Threaded
Open this post in threaded view
|

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

Mark Geisert
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<[hidden email]>
>>>>>>>> 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
Reply | Threaded
Open this post in threaded view
|

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

Yaakov Selkowitz-2
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<[hidden email]>
> >>>>>>>> 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.


Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen
In reply to this post by Mark Geisert
On Jun 28 03:17, 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<[hidden email]>
> > > > > > > > > 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.
> > > > > > >
> > > [...]
> > > 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.
>
> > > [...]
> > > 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.
I'll push my patch, but it would be nice if we could provide the
definitions from http://man7.org/linux/man-pages/man3/CPU_SET.3.html as
well.


Thanks,
Corinna

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Corinna Vinschen
In reply to this post by Yaakov Selkowitz-2
On Jun 28 10:06, Yaakov Selkowitz wrote:

> On Fri, 2019-06-28 at 03:17 -0700, Mark Geisert wrote:
> > 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
Agreed.  We shouldn't release 3.1 without it.


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mark Geisert
Corinna Vinschen wrote:

> On Jun 28 10:06, Yaakov Selkowitz wrote:
>> On Fri, 2019-06-28 at 03:17 -0700, Mark Geisert wrote:
>>> 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
>
> Agreed.  We shouldn't release 3.1 without it.

Fair enough on the requirement.  Just FYI I'll be AFK for two weeks beginning
July 4, so will try to get this done before I leave.  No big worry there.

Please forgive my ignorance of licensing details...  Are we allowed to copy GNU
library source into Cygwin?  Or is re-implementation from documentation the way
to go?  In either case, must the glibc file organization be followed or is
platform-specific rejiggering acceptable?

I'd like to just add the CPU_SET macros to Cygwin's new sys/cpuset.h and any
needed support code to our sched.cc but am willing to hear other options.
Thanks,

..mark
Reply | Threaded
Open this post in threaded view
|

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

Eric Blake-3
On 6/28/19 7:57 PM, Mark Geisert wrote:

>
> Please forgive my ignorance of licensing details...  Are we allowed to
> copy GNU library source into Cygwin?

Cygwin is a different beast (it has GPL code, but still tries to avoid
wholesale imports from glibc, preferring to copy from BSD where
possible).  But you asked a question on the newlib list, and here the
answer is a definitive now - newlib cannot include [L]GPL code, so
copying from glibc is forbidden.

>  Or is re-implementation from
> documentation the way to go?

Correct, unless you can find an existing BSD implementation with
appropriate semantics to copy.

>  In either case, must the glibc file
> organization be followed or is platform-specific rejiggering acceptable?

The more you copy glibc's layout, the more questionable it is on whether
you did inappropriate copying. What matters more is getting something
that implements the right semantics.

>
> I'd like to just add the CPU_SET macros to Cygwin's new sys/cpuset.h and
> any needed support code to our sched.cc but am willing to hear other
> options.
> Thanks,
>
> ..mark
>

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Brian Inglis

On 2019-06-29 06:38, Eric Blake wrote:

> On 6/28/19 7:57 PM, Mark Geisert wrote:
>> Please forgive my ignorance of licensing details...  Are we allowed to
>> copy GNU library source into Cygwin?
> Cygwin is a different beast (it has GPL code, but still tries to avoid
> wholesale imports from glibc, preferring to copy from BSD where
> possible).  But you asked a question on the newlib list, and here the
> answer is a definitive now - newlib cannot include [L]GPL code, so
> copying from glibc is forbidden.
>> Or is re-implementation from documentation the way to go?
> Correct, unless you can find an existing BSD implementation with
> appropriate semantics to copy.
>> In either case, must the glibc file organization be followed or is
>> platform-specific rejiggering acceptable?
> The more you copy glibc's layout, the more questionable it is on whether you
> did inappropriate copying. What matters more is getting something that
> implements the right semantics.
>> I'd like to just add the CPU_SET macros to Cygwin's new sys/cpuset.h and
>> any needed support code to our sched.cc but am willing to hear other
>> options.

As already mentioned, the required headers and macros already exist under:
https://cygwin.com/git/gitweb.cgi?f=newlib/libc/sys/rtems/include/sys;a=tree;p=newlib-cygwin.git
in _bitset.h, _cpuset.h, bitset.h, cpuset.h, and
https://cygwin.com/git/gitweb.cgi?f=newlib/libc/sys/linux/include/sched.h;a=blob;p=newlib-cygwin.git

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Huber-4
In reply to this post by Mark Geisert
On 29/06/2019 02:57, Mark Geisert wrote:

> Corinna Vinschen wrote:
>> On Jun 28 10:06, Yaakov Selkowitz wrote:
>>> On Fri, 2019-06-28 at 03:17 -0700, Mark Geisert wrote:
>>>> 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
>>
>> Agreed.  We shouldn't release 3.1 without it.
>
> Fair enough on the requirement.  Just FYI I'll be AFK for two weeks
> beginning July 4, so will try to get this done before I leave.  No big
> worry there.
>
> Please forgive my ignorance of licensing details...  Are we allowed to
> copy GNU library source into Cygwin?  Or is re-implementation from
> documentation the way to go?  In either case, must the glibc file
> organization be followed or is platform-specific rejiggering acceptable?
>
> I'd like to just add the CPU_SET macros to Cygwin's new sys/cpuset.h and
> any needed support code to our sched.cc but am willing to hear other
> options.

It would be nice to have a common Newlib implementation which can be
used for Cygwin, RTEMS and other systems. The RTEMS implementation is
BSD licensed and uses the FreeBSD BITSET(9) support:

https://www.freebsd.org/cgi/man.cgi?query=bitset&apropos=0&sektion=9

The goal of the RTEMS <sys/cpuset.h> is to provide the full glibc API

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

and as much as possible from FreeBSD CPUSET(9)

https://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=9&apropos=0

If you don't want the FreeBSD compatibility in Cygwin (it may confuse
configure scripts), then we can move this to a separate part and only
provide it by RTEMS.

--
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  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.