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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 CA4FBC3F2D7 for ; Wed, 4 Mar 2020 02:31:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A408320866 for ; Wed, 4 Mar 2020 02:31:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cs.washington.edu header.i=@cs.washington.edu header.b="S8jgdom0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387490AbgCDCbX (ORCPT ); Tue, 3 Mar 2020 21:31:23 -0500 Received: from mail-il1-f195.google.com ([209.85.166.195]:35270 "EHLO mail-il1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387454AbgCDCbX (ORCPT ); Tue, 3 Mar 2020 21:31:23 -0500 Received: by mail-il1-f195.google.com with SMTP id g126so522710ilh.2 for ; Tue, 03 Mar 2020 18:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iDh/enhDaAA8PUFA/sO33m/8w76mEhVPC2n0905OieU=; b=S8jgdom0wODh397o+u6x7vdYMOxPd/sn1jhl7jFTzqmZwArA/RGIOqXd1Lfk54/0Vl OnuKtqPJi4jEGtECkwc5BXE+qT27/RonNFdTLx9kPE210O+Z5T2l6hPG58KWXs+eDdf1 pHa2aWWb75igheHNKaBH3PpojCyHVsQH0TMYk= 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:content-transfer-encoding; bh=iDh/enhDaAA8PUFA/sO33m/8w76mEhVPC2n0905OieU=; b=dP3dYQ4GX1zb8ihNJIkJkltn3T0sI/aFumaQmR00JFYKoMqRPMKeCc7ljzEOTkpX7k IvM32HGPgcFdumEPxXIh88mEQgFw2EKW1bg/Ka9gUsPD2J/16aoHe1NaoYKy0dHRxwSK Djm8MugtcV/dUdYD4HeoQQBF4EYi8ppDMLaznsZXZaNX+dzMUv10f/W7eTBEpBUzuRdc DzLMGYqwLc3FGyaZ8QPqfrd9DjUO3QizmGgU3YfpMfrW+OJojotGx71Dn8jv/XrHzJpy 9gA6gLenC9gY9dGEjkN46BIKPL7Mw+xDXTMd1D8SenvRTz4AaejRCzbcRngIzbKEXOU2 C1Yw== X-Gm-Message-State: ANhLgQ3w4/TlUSYsaGHe0lEOOIgNkZRre7mJoSYiJEXH9vJHi9Q6CBXE 2NgYtCSRwzZAXfXnMWK55uUyMUfk6AMXwsN0YwV2UQ== X-Google-Smtp-Source: ADFU+vtpJ/AVr87l3sVJ8pp3Eu7HomjQQiORzxtMTMauDedmgqcfPEE0GdUhImRuEnjWdcebpvzP0Zzi0Nqw6HfYP3A= X-Received: by 2002:a92:860a:: with SMTP id g10mr674584ild.280.1583289081991; Tue, 03 Mar 2020 18:31:21 -0800 (PST) MIME-Version: 1.0 References: <20200303005035.13814-1-luke.r.nels@gmail.com> <20200303005035.13814-2-luke.r.nels@gmail.com> In-Reply-To: From: Luke Nelson Date: Tue, 3 Mar 2020 18:31:11 -0800 Message-ID: Subject: Re: [PATCH bpf-next v4 1/4] riscv, bpf: move common riscv JIT code to header To: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= Cc: bpf , Luke Nelson , Jonathan Corbet , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , "David S. Miller" , Jakub Kicinski , Paul Walmsley , Palmer Dabbelt , Albert Ou , Xi Wang , Mauro Carvalho Chehab , Stephen Hemminger , Rob Herring , Greg Kroah-Hartman , Jonathan Cameron , Andy Shevchenko , linux-doc@vger.kernel.org, LKML , Netdev , linux-riscv@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Bj=C3=B6rn, Thanks for the comments! Inlined responses below: On Mon, Mar 2, 2020 at 11:50 PM Bj=C3=B6rn T=C3=B6pel wrote: > > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Common functionality for RV32 and RV64 BPF JIT compilers > > + * > > + * Copyright (c) 2019 Bj=C3=B6rn T=C3=B6pel > > + * Copyright (c) 2020 Luke Nelson > > + * Copyright (c) 2020 Xi Wang > > I'm no lawyer, so this is more of a question; You've pulled out code > into a header, and renamed two functions. Does that warrant copyright > line additions? Should my line be removed? This header also includes new code for emitting instructions required for the RV32 JIT (e.g., sltu) and some additional pseudoinstructions (e.g., bgtu and similar). I'm also no lawyer, so I don't know either if this rises to the level of adding copyright lines. I'm happy to do the following in v5 if it looks better: + * Copyright (c) 2019 Bj=C3=B6rn T=C3=B6pel + * + * Modified by ... > > +#if __riscv_xlen =3D=3D 64 > > Please remove this. If the inlined functions are not used, they're not > part of the binary. This adds complexity to the code, and without it > we can catch build errors early on! I agree in general we should avoid #if. The reason for using it here is to cause build errors if the RV32 JIT ever tries to emit an RV64-only instruction by mistake. Otherwise, what is now a build error would be delayed to an illegal instruction trap when the JITed code is executed, which is much harder to find and diagnose. We could use separate files, bpf_jit_32.h and bpf_jit_64.h (the latter will include the former), if we want to avoid #if. Though this adds another form of complexity. So the options here are 1) using no #if, with the risk of hiding subtle bugs in the RV32 JIT; 2) using #if as is; and 3) using separate headers. What do you think? Thanks! Luke