public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: Florian Weimer <fw@deneb.enyo.de>,
	Joseph Myers <joseph@codesourcery.com>
Cc: Alistair Francis <alistair23@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Zack Weinberg <zackw@panix.com>, Arnd Bergmann <arnd@arndb.de>,
	GNU C Library <libc-alpha@sourceware.org>,
	Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	Florian Weimer <fweimer@redhat.com>,
	Carlos O'Donell <carlos@redhat.com>,
	Stepan Golosunov <stepan@golosunov.pp.ru>
Subject: Re: [PATCH v8 1/3] y2038: Introduce internal for glibc struct __timespec64
Date: Wed, 25 Sep 2019 14:38:00 -0000	[thread overview]
Message-ID: <20190925163818.5e8a3a03@jawa> (raw)
In-Reply-To: <87lfucsddd.fsf@mid.deneb.enyo.de>

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

Hi Florian,

> * Lukasz Majewski:
> 
> >> 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.  
> 
> I think we cannot support those kernels with reasonable effort.  So
> cross-architecture source compatibility with existing practices is
> more important.

I see your point.

> 
> Furthermore, I think the consensus for the public struct timespec64 is
> that it should use an unnamed bitfield because of the prevalence of
> incorrect (according to POSIX) initializers.

Yes. Correct.

> 
> >> 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].  
> 
> > Links:
> > [1] - https://sourceware.org/ml/libc-alpha/2019-05/msg00151.html  
> 
> The patch has a named bitfield:
> 
> +  int tv_pad: 32;            /* Padding named for checking/setting */
> 

Ach. Yes indeed - there was a _named_ bitfield in the patch. 

> As far as I can see, the discussion was about what was actually in the
> patch, and not an unnamed bitfield.

Yes, you seems to be right. Andreas objection was about the bitfield
usage.


Let's wait for Joseph's opinion if we shall replace named padding struct
members with unnamed bitfields (and drop potential support for fixing
issues, which would require explicit clearing of padding before passing
data to the kernel). 


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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-09-25 14:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-18 21:16 [PATCH v8 0/3] y2038: Linux: Introduce __clock_settime64 function Lukasz Majewski
2019-09-18 21:16 ` [PATCH v8 3/3] y2038: linux: Provide __clock_settime64 implementation Lukasz Majewski
2019-09-18 21:43   ` Joseph Myers
2019-09-18 22:34     ` Lukasz Majewski
2019-09-19 22:01       ` Lukasz Majewski
2019-09-18 21:16 ` [PATCH v8 2/3] y2038: Provide conversion helpers for struct __timespec64 Lukasz Majewski
2019-09-19 20:17   ` Joseph Myers
2019-09-19 21:21     ` Lukasz Majewski
2019-09-19 21:29       ` Joseph Myers
2019-09-19 22:03         ` Lukasz Majewski
2019-09-19 22:17           ` Joseph Myers
2019-09-19 22:22             ` Lukasz Majewski
2019-09-18 21:16 ` [PATCH v8 1/3] y2038: Introduce internal for glibc " Lukasz Majewski
2019-09-19 20:14   ` Joseph Myers
2019-09-23 21:22     ` Lukasz Majewski
2019-09-25  0:47       ` Joseph Myers
2019-09-25  7:45         ` Lukasz Majewski
2019-09-25 12:51           ` Florian Weimer
2019-09-25 13:34             ` Lukasz Majewski
2019-09-25 13:40               ` Florian Weimer
2019-09-25 14:38                 ` Lukasz Majewski [this message]
2019-09-25 16:29                   ` Joseph Myers
2019-09-25 20:03                     ` Lukasz Majewski
2019-09-25 12:43   ` Florian Weimer
2019-09-25 13:06     ` Lukasz Majewski
2019-09-25 13:07       ` Florian Weimer
2019-09-18 23:37 ` [PATCH v8 0/3] y2038: Linux: Introduce __clock_settime64 function Alistair Francis
2019-09-19  7:51   ` Lukasz Majewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190925163818.5e8a3a03@jawa \
    --to=lukma@denx.de \
    --cc=adhemerval.zanella@linaro.org \
    --cc=alistair.francis@wdc.com \
    --cc=alistair23@gmail.com \
    --cc=arnd@arndb.de \
    --cc=carlos@redhat.com \
    --cc=fw@deneb.enyo.de \
    --cc=fweimer@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=stepan@golosunov.pp.ru \
    --cc=zackw@panix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).