From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38968 invoked by alias); 6 May 2019 21:15:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 38900 invoked by uid 89); 6 May 2019 21:15:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,GARBLED_BODY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 spammy=Youll, You'll X-HELO: mail-out.m-online.net Date: Mon, 06 May 2019 21:15:00 -0000 From: Lukasz Majewski To: Stepan Golosunov Cc: Joseph Myers , libc-alpha@sourceware.org, Arnd Bergmann , Paul Eggert Subject: Re: [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define Message-ID: <20190506231444.088274fc@jawa> In-Reply-To: <20190506193617.nd44jtdt4tty5few@sghpc.golosunov.pp.ru> References: <20190429104613.16209-1-lukma@denx.de> <20190429104613.16209-3-lukma@denx.de> <20190430110505.2a0c7d1a@jawa> <20190430214748.rzjlcu3f3hdyqnhw@sghpc.golosunov.pp.ru> <20190502105108.541fe118@jawa> <20190502115459.d3qwvhvmzl6c5kmo@sghpc.golosunov.pp.ru> <20190502155549.2f7bf82d@jawa> <20190506153844.77cad546@jawa> <20190506162659.6d7e4a59@jawa> <20190506193617.nd44jtdt4tty5few@sghpc.golosunov.pp.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/CCveSGLfxcN_AtobggAai7N"; protocol="application/pgp-signature" X-SW-Source: 2019-05/txt/msg00085.txt.bz2 --Sig_/CCveSGLfxcN_AtobggAai7N Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-length: 3807 Hi Stepan, > 06.05.2019 =D0=B2 16:26:59 +0200 Lukasz Majewski =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0=D0=BB: >=20 > > > > > > > I believe that the only 32-bit architecture without > > > > > > > __NR_clock_settime64 is x32.=20=20=20=20=20=20=20=20=20 > > > > > >=20 > > > > > > Ok, I see.=20 > > > > > >=20 > > > > > > Please correct me - would it be feasible to just #undef > > > > > > __ASSYME_TIME64_SYSCALLS for x32 ?=20=20=20=20=20=20=20=20 > > > > >=20 > > > > > You'll need to know whether to use __NR_clock_settime64 or > > > > > __NR_clock_settime in cases where __TIMESIZE =3D=3D 64 and > > > > > __WORDSIZE =3D=3D 32.=20=20=20=20 > > >=20 > > > Please correct me, but I do have some doubts here. > > >=20 > > > As x32 now uses 64 bit time (and has TIMESIZE=3D=3D64) - it uses the > > > clock_settime call (with in-kernel broken tv_nsec padding > > > clearing - but for this the fix is in its way to upstream). > > >=20 > > > Why does it need to also support clock_settime64 ?=20=20=20 > >=20 > > I was too eager to send the mail. > >=20 > > It is connected with your proposition to use __WORDSIZE for #ifdef > > on __ASSUME_TIME64_SYSCALLS.=20 > >=20 > > As x32 has __WORDSIZE=3D32 (but __TIMESIZE=3D64), it would fall into > > "category" of archs using explicit 64 bit calls (i.e. > > clock_settime64). > >=20 > > However, for it - those shall be replaced with syscalls used up > > till now (i.e. clock_settime). > >=20 > > Am I right here ?=20=20 >=20 > x32 has __WORDSIZE=3D=3D32 and __TIMESIZE=3D=3D64. Future 32-bit > architectures should have __WORDSIZE=3D=3D32 and __TIMESIZE=3D=3D64 too. = And > the only difference in implementation of clock_settime64 function > there should be name of syscall (ignoring possible padding clearing > issues). For ARM, x86 there shall be call to clock_settime64 syscall For x32 there shall be call to clock_settime syscall (which is supporting 64 bit anyway - despite the ignoring possible padding clearing issue). >=20 > > > > > One way would be by defining __ASSUME_TIME64_SYSCALLS > > > > > unconditionally on x32 and then defining __NR_clock_settime64 > > > > > to __NR_clock_settime when __ASSUME_TIME64_SYSCALLS is > > > > > defined while __NR_clock_settime64 isn't.=20=20 >=20 > I think now that with this scheme __ASSUME_TIME64_SYSCALLS should be > defined unconditionally for the __WORDSIZE=3D=3D64 case too. With this > there will be no need to use __TIMESIZE inside clock_settime64 > function. __TIMESIZE describes interfaces provided by glibc, and has > no relation with kernel interfaces used by glibc. >=20 > #ifdef __ASSUME_TIME64_SYSCALLS > call __NR_clock_settime64 (possibly defined to __NR_clock_settime) > #else > call __NR_clock_settime64 with fallback to __NR_clock_settime on > ENOSYS #endif I rather thought about something like: __clock_settime64 (clockid_t clock_id, const struct __timespec64 *tp) { #ifdef __ASSUME_TIME64_SYSCALLS # ifdef __NR_clock_settime64 int ret =3D INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp); if (ret =3D=3D 0 || errno !=3D ENOSYS) return ret; # endif /* Fall back to syscall supporting 32bit struct timespec. */ struct timespec ts32; valid_timespec64_to_timespec (tp, &ts32); return INLINE_SYSCALL_CALL (clock_settime, clock_id, &ts32); #else /* 64 bit machines + x32 */ return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp); #endif } In the above pseudo code we assume that __ASSUME_TIME64_SYSCALLS is #undef'ed for x32 (so it is treated as a 'special case' - in the same way as x86_64). 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 --Sig_/CCveSGLfxcN_AtobggAai7N Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature Content-length: 488 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAlzQo8UACgkQAR8vZIA0 zr3LWQf+NYmITDV7OxoCYQgDyTKBPBZpXPk4wcO4isy8umYm77gHjArQ2y637nxO 8Pb+8tehDQs/jdtSzoGJSGchd7oucReicnEfP3P7/1EQw1NajdielTkmwagBxXZw QqxZyPC6AoI57cM8ohzrGBMYEMyIgGR+IbUlO0HBat58zB6hNEzdpXIO4hFMkGH/ 2pKB/o3SGzf6MdXPlyyfQFKPAEr2bHmGW24Jkh/YXu9RhKIT/LJXnIwz5lejXyhE kepXNTpJ+fQpLB34sRgQG1grrGu8MRDHicQr7x+SHiy2FzNE1BWqsAuTqNd+6O// 5y6qBWj0Hc5xEpvC2PZenrdrNKFvxg== =rCi/ -----END PGP SIGNATURE----- --Sig_/CCveSGLfxcN_AtobggAai7N--