From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 68DC2386483F for ; Tue, 20 Jul 2021 08:53:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 68DC2386483F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-331-VHF3gEaZPQKB-NFF_l9xRw-1; Tue, 20 Jul 2021 04:53:01 -0400 X-MC-Unique: VHF3gEaZPQKB-NFF_l9xRw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA1CD362FB; Tue, 20 Jul 2021 08:53:00 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-73.phx2.redhat.com [10.3.112.73]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CF4265C1D1; Tue, 20 Jul 2021 08:52:59 +0000 (UTC) From: Florian Weimer To: Lukasz Majewski Cc: Florian Weimer via Libc-alpha Subject: Re: [PATCH 1/8] misc: Add time64 alias for ioctl References: <20210720103245.491b5bfa@ktm> Date: Tue, 20 Jul 2021 10:52:57 +0200 In-Reply-To: <20210720103245.491b5bfa@ktm> (Lukasz Majewski's message of "Tue, 20 Jul 2021 10:32:45 +0200") Message-ID: <87eebttlhy.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 08:53:04 -0000 * Lukasz Majewski: > So the idea here is to have the distinction for ioctl's when we decide > to support 64 bit time on 32 bit ports? And as ioctls are often > multiplexed, we will not be able to distinct the time related struct > members passed to this syscall? The idea is this: If we need to add more ioctl rewriting in userspace, then we can confie that to time64 binaries with this change because they use a separate function call. Binaries which use the non-time64 interface (especially old binaries which cannot be recompiled) are totally unaffected by such potential future changes. If there is no separate time64 symbols, we would have to hope that we can identify the need to rewrite based on the arguments alone, which is likely but not guaranteed. Thanks, Florian