Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64

[Lukasz Majewski <lukma at denx dot de>]

Hi Florian,

> * Lukasz Majewski:
> 
> >> I think it's generally for reviewers to say if their view is "I
> >> think this patch is OK but we should allow more time for other
> >> people to comment", rather than expecting patch contributors to
> >> judge when they need to wait further after a patch approval.  
> >
> > Yes. I do understand.
> >
> > If I may ask - what is the "acceptable" time for other people from
> > community to jump in and comment the patch before it shall be
> > applied?
> >
> > Is it one week or more/less ?  
> 
> A week is more than enough, especially for patches that only touch
> internals like this one.

Thanks for clarification.

> 
> Regarding the actual patch, I don't understand why tv_pad isn't an
> *anonymous* bit field. 

The reason for this is that we may need to clear this padding if we
plan to fix some issues - for example in kernel 5.1.0 - 5.1.4 there is
a bug for x32 which may require explicit clearing the padding.

> This seems to introduce unnecessary variance
> between architectures and is incompatible with how glibc itself uses
> struct timespec. 

The v3 of this patch had this field defined as anonymous padding.
However, there was strong objection for such approach [1].

> It's also inconsistent with the new comment in
> include/time.h (named padding is only needed if you need to
> zero-initialize the padding).

As explained above - some archs/kernels may require this named padding
for fixes.


Links:
[1] - https://sourceware.org/ml/libc-alpha/2019-05/msg00151.html

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Attachment: pgpWPRJHQKV8M.pgp
Description: OpenPGP digital signature