Re: Upstreaming the glibc Hurd port

[Zack Weinberg <zackw@panix.com>]

On Wed, Apr 18, 2018 at 10:03 AM, Samuel Thibault
<samuel.thibault@gnu.org> wrote:
>>
>> I have a concern: the types 'struct sched_param' and 'struct
>> __sched_param' are not compatible, even if their members are identical
>> (6.2.7p1 explicitly requires the tags to be the same for
>> compatibility).
>
> Ah, probably that's why bits/sched.h used to define both sched_param and
> __sched_param with the __sched_priority field, and #define
> sched_priority to __sched_priority.  I can do that, it's fine.

This is actually worse than having struct sched_param defined by
sys/types.h, because sched.h is now defining *macro* names that it's
not supposed to.  It's far more likely that a program will try to
define a variable named 'sched_priority' than that it will try to
define its own 'struct sched_param'.

Can I ask whether you want to keep exposing the internals of pthread_*
types to applications?  If there's a plan to stop doing that - even a
"yeah but it's hard and we have so many other things to do first"
intention - then I would recommend leaving sched_param alone for now
and just XFAILing the conformance test.  On the other hand, if you
actively want to keep them exposed and encourage applications to use
them, then there does need to be some kind of workaround.

zw