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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5039AC433EF for ; Fri, 15 Oct 2021 06:11:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E297B60F59 for ; Fri, 15 Oct 2021 06:11:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E297B60F59 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 6CDCD6B006C; Fri, 15 Oct 2021 02:11:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 67D936B0071; Fri, 15 Oct 2021 02:11:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 593A36B0072; Fri, 15 Oct 2021 02:11:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id 4ADFC6B006C for ; Fri, 15 Oct 2021 02:11:39 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id F0FB0183AB0A6 for ; Fri, 15 Oct 2021 06:11:38 +0000 (UTC) X-FDA: 78697650276.11.13088A8 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by imf28.hostedemail.com (Postfix) with ESMTP id AE93890000B4 for ; Fri, 15 Oct 2021 06:11:38 +0000 (UTC) Received: by mail-pj1-f48.google.com with SMTP id e5-20020a17090a804500b001a116ad95caso997495pjw.2 for ; Thu, 14 Oct 2021 23:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=plfcm4CfcUE1WiY9y7riQIhpNSbgCl5IoHQbTDcGsFg=; b=gieWljbKJwM9dQX6FOXQV2SpCe//Ev5ww9pOhDg5EdDrNtR5Lx0ZAL812Gu332zPKR UI7yMIUPu2HyloFVswy9HgPPvtbyrdczGYvnoHYakywHAaViHzL5uqFUKrFbnusGE78p FR7XkKvoEOhCvlYUoeVZCxWBtLpfk7zmIJS58MkCHqCV+yC9MSjQFbhk5uVvUNGtWoP6 NrG607qHVb55hKbFALyOZNpJTTziAS3sgyN27QNIhMeIclv5SsR4MDwB3hEMWWp7mZzz voySiAUFzvMaQB1oVslqz1NbLZ/onJvkQWpytWvGSHGyROoBeqZyXvFF/H15Cw767WGu 2/dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=plfcm4CfcUE1WiY9y7riQIhpNSbgCl5IoHQbTDcGsFg=; b=VDS5c0I6HhvK7Btn0dwLlBhRNqZOPiIhbHz0dWYz40w2b7p1o/nKxz/naEqxLZWcyJ w619JT8jU8LUlKP3H7z8L+U71s+LWj2x+rKbGS2aA6Eg5sX8ZsxHYdKlql/Ablw9LpQ4 1uoJcTGcnsMc3opgrRfvTm+ibaGsNFpO2Ieam9ALug+UINgID1PiwdeLkjCEmVHc5Hjn qOGn6hjHZeD2p6lavfigZPjj/917s4F1Wdn3LeeyVGuPt65NK81GWDMRBoWwciXEK2uh w7Zv1slxvWiwr7jsOSQTAGu97X1C+TN9Rwu4l/7QJH52oN2qPs2CkaO/HA8KtRIJrGO7 /82g== X-Gm-Message-State: AOAM532IoAQMcHQpoS8pqT7w2LX9mVf6vwxI0UV1rK/lqO5r1fKHwQn+ tk6Eg9sXG1DtZ93to0nF4mY= X-Google-Smtp-Source: ABdhPJw1NnFiRHA+uTmys9crR/a3G0Uc+wC/8h4OyGNNK2GxtvT1XWJX/yFt1VyNaMubShrCkR00uw== X-Received: by 2002:a17:902:6f01:b0:138:9aca:efda with SMTP id w1-20020a1709026f0100b001389acaefdamr9600787plk.19.1634278297562; Thu, 14 Oct 2021 23:11:37 -0700 (PDT) Received: from localhost (14-203-144-177.static.tpgi.com.au. [14.203.144.177]) by smtp.gmail.com with ESMTPSA id s22sm4032847pfe.76.2021.10.14.23.11.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Oct 2021 23:11:37 -0700 (PDT) Date: Fri, 15 Oct 2021 16:11:32 +1000 From: Nicholas Piggin Subject: Re: [PATCH v2 03/13] powerpc: Remove func_descr_t To: Andrew Morton , Arnd Bergmann , Benjamin Herrenschmidt , Christophe Leroy , Helge Deller , Daniel Axtens , Greg Kroah-Hartman , "James E.J. Bottomley" , Kees Cook , Michael Ellerman , Paul Mackerras Cc: linux-arch@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <16eef6afbf7322d0c07760ebf827b8f9f50f7c6e.1634190022.git.christophe.leroy@csgroup.eu> <874k9j45fm.fsf@dja-thinkpad.axtens.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <1634277766.29y8aqzatr.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AE93890000B4 X-Stat-Signature: ppwjeb35fnsmz9fwc3fpwzurg9zz5e81 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gieWljbK; spf=pass (imf28.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.48 as permitted sender) smtp.mailfrom=npiggin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1634278298-85169 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Excerpts from Christophe Leroy's message of October 15, 2021 3:19 pm: >=20 >=20 > Le 15/10/2021 =C3=A0 00:17, Daniel Axtens a =C3=A9crit=C2=A0: >> Christophe Leroy writes: >>=20 >>> 'func_descr_t' is redundant with 'struct ppc64_opd_entry' >>=20 >> So, if I understand the overall direction of the series, you're >> consolidating powerpc around one single type for function descriptors, >> and then you're creating a generic typedef so that generic code can >> always do ((func_desc_t)x)->addr to get the address of a function out of >> a function descriptor regardless of arch. (And regardless of whether the >> arch uses function descriptors or not.) >=20 > An architecture not using function descriptors won't do much with=20 > ((func_desc_t *)x)->addr. This is just done to allow building stuff=20 > regardless. >=20 > I prefer something like >=20 > if (have_function_descriptors()) > addr =3D (func_desc_t *)ptr)->addr; > else > addr =3D ptr; If you make a generic data type for architectures without function=20 descriptors as such typedef struct func_desc { char addr[0]; } func_desc_t; Then you can do that with no if. The downside is your addr has to be=20 char * and it's maybe not helpful to be so "clever". >> - why pick ppc64_opd_entry over func_descr_t? >=20 > Good question. At the begining it was because it was in UAPI headers,=20 > and also because it was the one used in our=20 > dereference_function_descriptor(). >=20 > But at the end maybe that's not the more logical choice. I need to look=20 > a bit more. I would prefer the func_descr_t (with 'toc' and 'env') if you're going=20 to change it. Thanks, Nick