From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CF8AC10F13 for ; Tue, 16 Apr 2019 10:02:47 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D87D6206B6 for ; Tue, 16 Apr 2019 10:02:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D87D6206B6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 44k1Br3tWJzDqBb for ; Tue, 16 Apr 2019 20:02:44 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=redhat.com (client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=fweimer@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 44k16g3zJNzDqFH for ; Tue, 16 Apr 2019 19:59:07 +1000 (AEST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D9B9630832EF; Tue, 16 Apr 2019 09:59:05 +0000 (UTC) Received: from oldenburg2.str.redhat.com (unknown [10.36.118.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ADBE25D9D3; Tue, 16 Apr 2019 09:59:04 +0000 (UTC) From: Florian Weimer To: hpa@zytor.com Subject: Re: [PATCH] Linux: Define struct termios2 in under _GNU_SOURCE [BZ #10339] References: <875zrnlakd.fsf@oldenburg2.str.redhat.com> <284e9c76-2411-b8f4-c4bc-c25c60c04cf7@linaro.org> <87imvker6t.fsf@oldenburg2.str.redhat.com> <87lg0fbr1q.fsf@oldenburg2.str.redhat.com> Date: Tue, 16 Apr 2019 11:59:03 +0200 In-Reply-To: (hpa's message of "Mon, 15 Apr 2019 08:53:02 -0700") Message-ID: <87lg0az2xk.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Tue, 16 Apr 2019 09:59:05 +0000 (UTC) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-api@vger.kernel.org, libc-alpha@sourceware.org, linuxppc-dev@lists.ozlabs.org, Adhemerval Zanella Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" * hpa: > Using symbol versioning doesn't really help much since the real > problem is that struct termios can be passed around in userspace, and > the interfaces between user space libraries don't have any > versioning. However, my POC code deals with that too by only seeing > BOTHER when necessary, so if the structure is extended garbage in the > extra fields will be ignored unless new baud rates are in use. That still doesn't solve the problem of changing struct offsets after a struct field of type struct termios. > Exporting termios2 to user space feels a bit odd at this stage as it > would only be usable as a fallback on old glibc. Call it > kernel_termios2 at least. I'm not sure why we should do that? The kernel calls it struct termios2 in its UAPI headers. If that name is not appropriate, it should be changed first in the UAPI headers. Thanks, Florian