From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 2D5083858D35 for ; Thu, 25 Jun 2020 07:33:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2D5083858D35 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-147-HL9VHGelObCx08fjnG7Y0g-1; Thu, 25 Jun 2020 03:33:30 -0400 X-MC-Unique: HL9VHGelObCx08fjnG7Y0g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EF438EC1A1; Thu, 25 Jun 2020 07:33:28 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-127.ams2.redhat.com [10.36.113.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 274A471698; Thu, 25 Jun 2020 07:33:27 +0000 (UTC) From: Florian Weimer To: "H.J. Lu via Libc-alpha" Subject: Re: V4: [PATCH] x86: Install [BZ #26124] References: <20200617193100.1115529-1-hjl.tools@gmail.com> <87mu50rccl.fsf@oldenburg2.str.redhat.com> <87o8pbpiuy.fsf@oldenburg2.str.redhat.com> <87ftamg7ez.fsf@oldenburg2.str.redhat.com> <87a70ug5v8.fsf@oldenburg2.str.redhat.com> <871rm4bkj6.fsf@oldenburg2.str.redhat.com> <697cab8a-2d75-ef36-9e09-dbfe6daa4ae1@linaro.org> Date: Thu, 25 Jun 2020 09:33:26 +0200 In-Reply-To: (H. J. Lu via Libc-alpha's message of "Wed, 24 Jun 2020 14:10:19 -0700") Message-ID: <87a70r8urd.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 25 Jun 2020 07:33:33 -0000 * H. J. Lu via Libc-alpha: >> is not expected to be extendable. The macro API is not my favorite way of > > We can expand the cpuid array. We just need to add an alias to > __x86_get_cpu_features > with a new symbol version. Agreed, from a GNU gABI perspective. However, for some distributions, this requirement will put hardware enablement for new CPUs on hold until we have reworked our package dependency generation, so that we can express symbol-specific version information. Debian & downstreams can already do this, with some manual work, but Fedora & downstreams can only express versions on sonames. (Without these changes, we would have to backport the entire GLIBC_2.33 symbol set to get __x86_get_cpu_features@GLIBC_2.33, for example. This is not something we will be able to do in all cases, depending on the other changes that are going in.) Even then, we can only backport such changes if a glibc release has happened (so that we can be sure that the meaning of the symbol version will not change again). My proposal, where the index is passed to the function and the function returns the flag word, does not have these issues: old glibcs will simply return 0 flags, and the feature appears unusable/unavailable. This is what already happens with your approach, too, if we use more bits inside the existing array elements. I'm not entirely opposed to enhancing the RPM dependency generation, but I already tried once and couldn't get it done, and if I fail again, it might seriously impact CPU hardware enablement in Red Hat Enterprise Linux 9. I hope this explains my reservations about this interface design. Thanks, Florian