Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2529223imm; Thu, 7 Jun 2018 12:11:06 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKEKR1kErwxmogdW4VTq9F/19PScT7bpssBAybzekf7Zdg/Q9h6PEU0jyA3PJrwwuDF5lXk X-Received: by 2002:a62:d8c5:: with SMTP id e188-v6mr2860201pfg.151.1528398666640; Thu, 07 Jun 2018 12:11:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528398666; cv=none; d=google.com; s=arc-20160816; b=WKG9oxhIAfBWFWunKZStgBetFJ0Z//h5STGFGe/wXftL3BleC2ljT8lZan8nvMB4IF CyDMVYt6KPODTtGceMDTmkeF5keLH/a1giGXiGNbEFI55rEc6RWupKe3YOrCBF+QeqUe Hiq+kiwOZAEd2iTP3+7cHuhv9aAuXwcmFsHGCEdCo3f9JThPDzhMYMyPQ19YjQAN+lbL ZgVPUFzPBM1CLQAGC9R8W0v4Y2oVCEmtwGzDDvEL+ox9cxZdbb+pbD1Ix51AqIOFBBgk Z2nTV9DxqVFQw0yozyXDSHkSgBwIQhX9r40LfalYaCp6B/CAaAyQHEsISpYH/p3pm2qm hjzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=hAU99C9zD3UsghKcPiymqFmN6jOxU+sKBReB+2Fl77c=; b=z2IoM1IXNpfLV1pbboNud6UHfqaHIQtkgq8K81XuOaBaDvZMNDi4o4A1GFoB5W1gh9 21b0TVGaY5Rd7pUnPoTe5uaBGgFeCZAeUocFMkkjNb6PWxpfd/zL3bAw/b/MddV3+1/u bqSxHE9zsGPvX58BAO1xZxcJtWQ1t8x94/Z3rj4FoKsgH2P+rXMlb8iTdC1s9IAhUeQU Kr8mXS5CftXGbxT4MfMwiqOMk2FS8nsuNRWwKSG6wnqi0iPhJhERRJGHP5P53pyzP7De J4XWhNPBVynotHKlIpVT/twaOWL3HyVZERACNAM7d9Kx7JwJ0Wa/RNFLkgQusaZyP1NZ FMzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=UMYEGc+X; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o33-v6si7607984plb.432.2018.06.07.12.10.52; Thu, 07 Jun 2018 12:11:06 -0700 (PDT) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=UMYEGc+X; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753389AbeFGSwO (ORCPT + 99 others); Thu, 7 Jun 2018 14:52:14 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:33374 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753066AbeFGSwM (ORCPT ); Thu, 7 Jun 2018 14:52:12 -0400 Received: by mail-pg0-f65.google.com with SMTP id e11-v6so5183393pgq.0 for ; Thu, 07 Jun 2018 11:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hAU99C9zD3UsghKcPiymqFmN6jOxU+sKBReB+2Fl77c=; b=UMYEGc+XphVzhcWKKGYa4oeBMj6jIro6wZDDEEq3CJCRLsdiDq6FdCCyHzKHyYOrml gg5ik++TxRHx2iukX3iJSpGCdgzqo6YWbXsdltXF9vERu/ZNlXN66tXHTauYONCrEq56 CNO/9EVaFZMRRFZgcbGnIaJ1Lt4vbgHZlXZQRaGCOw+2s/Lq/VoZtT10+G/onwuMcvOc eE1gTSn3nfvvNiPvIjvAG0cnyiJnRwMD1TZAH+hbDZjh5HwPgyRbAniM5nnpS5EyJdUk tHdmuW7TKhe5dVC27e21sLxE/YWrOcxviN9qgKhsoVfCOU5mLu3hpNggZNB0WSOEgZ6T pavg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hAU99C9zD3UsghKcPiymqFmN6jOxU+sKBReB+2Fl77c=; b=BhUL+de3M69q9BKO3Tlnh7tpUY0ZVekd6eOX7NQSOYc7wXQkkhCeFyLq9wqIkltfVp EMT8u0cS5+xJAd8O4zUj6zwfN7zS7qgd+mYYPELh0VFRCDy1li8Mi/UDUR7BpM+pmund IDHFBNxfEsA01MeoY2YgAWYW9kcc8OR1MNlpBhe947YH7w4l0X4D21+1Kp09DMqQ1Lt8 DYTMgeLPB9uvxAeZ62XBOEA89s+QQkz5+XJZ5WrehtP5c4uYo2YyrIHO3GTfZ85rX5aX T7rD/ejFaxdSNqWIDSCPa/k+WSMroEkZJHHN2Mge5/h2R5jfq8zjDCWGFTrIcivTmS5P se2g== X-Gm-Message-State: APt69E3O+imCb4kD/NqH2ibkSFNdMRXDB4fJfkV3YafTTU+tMlPwp6cv TTr3xqG2y3DU7UKnEofDvMyUQuX3DjpU2F9/NV+mVA== X-Received: by 2002:a63:af50:: with SMTP id s16-v6mr2563785pgo.263.1528397531471; Thu, 07 Jun 2018 11:52:11 -0700 (PDT) MIME-Version: 1.0 References: <20180605170532.170361-1-ndesaulniers@google.com> <20180605170532.170361-2-ndesaulniers@google.com> <202492204c2d5bd5ca27307cbca5e44673b739ed.camel@perches.com> <28c288fd3e87b6c839697519043cf642518e0262.camel@perches.com> In-Reply-To: <28c288fd3e87b6c839697519043cf642518e0262.camel@perches.com> From: Nick Desaulniers Date: Thu, 7 Jun 2018 11:51:59 -0700 Message-ID: Subject: Re: [PATCH v2 1/2] compiler-gcc.h: add gnu_inline to all inline declarations To: joe@perches.com Cc: Andrew Morton , Ard Biesheuvel , Andrey Ryabinin , akataria@vmware.com, boris.ostrovsky@oracle.com, brijesh.singh@amd.com, Cao jin , Greg KH , hpa@zytor.com, "J. Kiszka" , jarkko.sakkinen@linux.intel.com, jgross@suse.com, Josh Poimboeuf , kirill.shutemov@linux.intel.com, mingo@redhat.com, mjg59@google.com, Matthias Kaehlcke , Philippe Ombredanne , rostedt@goodmis.org, Thomas Gleixner , thomas.lendacky@amd.com, Thiebaud Weksteen , linux-efi@vger.kernel.org, LKML , x86@kernel.org, virtualization@lists.linux-foundation.org, Alistair Strachan , Manoj Gupta , Greg Hackmann , sedat.dilek@gmail.com, tstellar@redhat.com, Kees Cook , Masahiro Yamada , Michal Marek , Linux Kbuild mailing list , geert@linux-m68k.org, Will Deacon , mawilcox@microsoft.com, Arnd Bergmann , David Rientjes Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 7, 2018 at 11:31 AM Joe Perches wrote: > > On Thu, 2018-06-07 at 10:26 -0700, Nick Desaulniers wrote: > > I get the feeling that the use of __inline__ or __inline (vs inline) > > in the kernel may be wrong and their use should be eradicated in the > > follow up patch set, but it would be cool if others have additional > > insight. > > __inline is easy and useful to remove as it's used in > just a few files. > > But __inline__ is used in a lot of files and locations: > > $ git grep -w --name-only __inline__ | wc -l > 154 > $ git grep -w __inline__ | wc -l > 503 > > Some of these files are used in asm includes as > well where __inline__ may be preferred by gcc > > https://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html#Alternate-Keywords > > so perhaps asm exclusions would be necessary. Oops, just saw this email after sending v3: https://lkml.org/lkml/2018/6/7/1055 Guess I should re-add __inline__ and __inline then to 1/3? https://lkml.org/lkml/2018/6/7/1060 ie: +#define __inline__ __inline__ inline instead of +#define __inline__ inline ? On the other hand, I was able to assemble with gcc+binutils and v3 as it stands. Reading the link you sent, it seems more about compiling with -pedantic or non-gnu C standards being used (I'd call that unlikely for the kernel). So it still seems incorrect to me the use of __inline__ (but I do appreciate the link!) at least in the kernel.