Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4495601ybf; Wed, 4 Mar 2020 05:11:02 -0800 (PST) X-Google-Smtp-Source: ADFU+vvzxkyaZ0rG5pUsslXtPcWmovSsQ213K9YXog3vwS3olmMNWID+VciI9ykakDA0AMoKFsE7 X-Received: by 2002:a9d:5e04:: with SMTP id d4mr334268oti.36.1583327462098; Wed, 04 Mar 2020 05:11:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583327462; cv=none; d=google.com; s=arc-20160816; b=qFlnkCzf8SM/w+zphVZAgRdk8tIe9cLrmWW/xeaHY6huQRmNTCPTmauTUPVfLxUbYF Vimptkg5rNfpKqG/3H3qR5dbrJP2UXbHxW0E0OKT0spnEFzCahL3aB08LJr02gq9Gbbj tNz0tPPTruZMBGzJFAQxccQC2tDGX0agWuw5QVT629+39fuY7T2OTWNFOg8QHE1ZCMxk JYjAKJM/Potq3m8vya9uDM/rQbRtGfsML8PFFlquO86nqZ76Qr60rRIgrmin2SmvuAcH XMgaMk3IB576deN7NDTpU1vqJFgTWBFxtIPLmKUmI2KBoKlRbqAr53jLKCzwzQ0DjUgv jLkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=MhqEH+wAEFIf7jBf1cUNkqtA+3LMhB3Vewum12azsfk=; b=dn7uA/qdhifYNY/MRdoBYJdbvOh83ukAR58P57/AbYsUAzCxCAtqJRgs49hUKsdIA8 LC3aVezwj/o6r9n6i/GwhY1Ta9AAyoxATFseqNGW11wp5Cta2DQ/K3kKLgFbyaUun2Ba FdZP11foUnkTP8Zv/aeJZTEoPLFjPn2STsjs7YtLmBqeaFdmWkx+PdG/C7FhvXPoIX4a oMKVcbZMbD8uXmbhM4fgNsfygJJYV5U92ursCGOWYGrqaPbwOCf8CeUdIZ5J9b/iyk6R dNZa++APgNEBoYgxD6lkUjkDFT4jz8I7jDB8gFsR5r+iCMe9gLmAtJ44wKwAslkhPhWb gsiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6si1040244otk.171.2020.03.04.05.10.47; Wed, 04 Mar 2020 05:11:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388152AbgCDNKP (ORCPT + 99 others); Wed, 4 Mar 2020 08:10:15 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:47336 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388147AbgCDNKP (ORCPT ); Wed, 4 Mar 2020 08:10:15 -0500 Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j9Tmf-0003gq-Ff; Wed, 04 Mar 2020 14:09:57 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id E62A8101161; Wed, 4 Mar 2020 14:09:56 +0100 (CET) From: Thomas Gleixner To: Alexandre Chartre , LKML Cc: x86@kernel.org, Steven Rostedt , Brian Gerst , Juergen Gross , Paolo Bonzini , Arnd Bergmann Subject: Re: [patch 08/24] x86/entry: Convert Divide Error to IDTENTRY In-Reply-To: <4afd832a-2a78-798a-97e0-d1e3636cc290@oracle.com> References: <20200225221606.511535280@linutronix.de> <20200225222648.970676604@linutronix.de> <4afd832a-2a78-798a-97e0-d1e3636cc290@oracle.com> Date: Wed, 04 Mar 2020 14:09:56 +0100 Message-ID: <87lfogl10b.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alexandre Chartre writes: > On 2/25/20 11:16 PM, Thomas Gleixner wrote: >> +/* Simple exception entries: */ >> +DECLARE_IDTENTRY(X86_TRAP_DE, exc_divide_error); >> + > > I think this macro has a tricky behavior because it will declare C functions > when included in a C file, and define assembly idtentry when included in an > assembly file. > > I see your point which is to have a single statement which provides both C > and assembly functions, but this dual behavior is not obvious when reading > the code. Maybe add a comment to explain this behavior? Done.