Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp474154iob; Wed, 18 May 2022 06:20:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwiefAvpXwT0+k1pvex4gB85Wg6RyL4H/kMcQ5aqseizYkuqBy+LFAXruDQ4B8WbHkck/L X-Received: by 2002:a17:902:ec8c:b0:161:cff5:1799 with SMTP id x12-20020a170902ec8c00b00161cff51799mr704972plg.64.1652880022778; Wed, 18 May 2022 06:20:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652880022; cv=none; d=google.com; s=arc-20160816; b=bVRjyfIpj9Z62tHp5RmO4qbEyRzeubCRgJ6ET+v+HmdY0/TvJaJTwnTS0jrvZTCUEI 4n3kA9gcdGJGP600ukc7I5TNK+ItMLhTicDqq/lMu2sR3aj1O/Tp81tIjBGdvAP0JXq3 xu65ItFRl+fkHfs4oFamlN/qmGQxvUley/S96RZLYlotMsVe8/bEV94HHX6a1bFV7uy2 h3TwR9UAiQHKwLyRnxtrEzICIziDJntcyVcO31dULWIGhCPTOQ2d4PPTk8+Adwd0mACF 6aLB7DTlQ0CmdDn7EO96Gl5xkoj9ITUrDAkErmwVjsYzmqXJG+58iEAXP2Id6UCqhUQ/ lVPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=+smhDklrrGEtZukDy4Hjv7j7ZEXxpHcmuXh1YussnDE=; b=Mf9SJ5mxAWz3MlrGyDH4DpCPcumTbqqvPZoHzDSCJFyTIH+hfiHTiiiiznYGxGMjpY AXCfkevaHpOtBLBqmAY83p39iZNWEGrH2gRDpJapeRcHKve6rgqQiAsFuSSPOyfJNUsR c28EvLVF8EuGyj4YTyWPnvRzV7dVCVMy3LNyuMT/W374bKCQ1pf0xhbInOuFV/yYVT8E CkkL4bvcag0K7Xw4/XZ7SA63gWd4N3UuAEPBAILHxqVi/0Eup/1cFF98h6rt/1d7ocar O+t78RJGWSYYVFeGTRElOz6Q51ildr2llnSot98J+LtgjM6YikLGkQpFOm7pUeNatTyj FJ8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=poNiieTG; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id a9-20020a056a000c8900b004fa3a8e0069si3151557pfv.288.2022.05.18.06.20.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 06:20:22 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=poNiieTG; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 27B8495A24; Wed, 18 May 2022 06:16:58 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237599AbiERNQs (ORCPT + 99 others); Wed, 18 May 2022 09:16:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237737AbiERNQW (ORCPT ); Wed, 18 May 2022 09:16:22 -0400 Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CCB222BF4; Wed, 18 May 2022 06:16:21 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id o190so2136253iof.10; Wed, 18 May 2022 06:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+smhDklrrGEtZukDy4Hjv7j7ZEXxpHcmuXh1YussnDE=; b=poNiieTGfBVCTzm/RtJ5Opf0aJg1todK5NXub3aIjnSxqlNkXKQt1MJdDOvcm5/6mS pqNWbx0zuvWaNSK3NrkuNSskINWiSHCKWG2OR+8FYJ6pxZig0ZzOlBtCnhGs2gvgD6Gg I5ydJGNeNgU22Btbn9s59FSdE56VH0PEe7Gh2/m1jiWz6QUYYYxEDYaKWfwilkIg9B3R MLbowC9QXWcCydVAghOSHZZv5bQi9TdL22jGijte3YUCvM9KxcCF0TA7v8oFw0dBsLGh DVQJoRmfoD7AdoUTdji2I5EMF2BWKaKX4K9A41vb6p3vgBF4QlGrJ7oBjvjuNy+zCu2r p7Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+smhDklrrGEtZukDy4Hjv7j7ZEXxpHcmuXh1YussnDE=; b=b4mST7ulvZD2bW6cd5dWpneWQdCEFigTRI1QqXYteeLUzEBUpNYajkr+qNwIbXx8Y9 SyT5JMY6plGjNf5J6g0vk/FLKXx+Oiuq8ST+qwQzDr02NAbzUD7wtEJfFrKAFIGZhnEy 2B8NItpNeBMqhFUZLYnNimygIgO0mpuwOff/XAnx8I+0dSTMzTydTn6FANp+JM9uY1LS yCNCMh5OMpY+2MQEuXB0fBLWD8NiDE4/AbcLXNqPFEB10xkzT3NybYsrUj8b/UmC5JR8 LNwzXEbs7SPAtROdU5YuOsiNNdc6XG6BolUBFlvMSJwFV1xsLGHa8l7xrkG1RNI5NDDJ gaOg== X-Gm-Message-State: AOAM5302ikHy+9+QCnLcnivFbg4sB7zpLL9OAAlPAtjdIzK+kdzZQXDs N3r/iD7djlx98ojS3XNfhkMbsidet8hwLPkGz6o= X-Received: by 2002:a05:6638:16cf:b0:32b:6ee7:8d7d with SMTP id g15-20020a05663816cf00b0032b6ee78d7dmr14548832jat.256.1652879780569; Wed, 18 May 2022 06:16:20 -0700 (PDT) MIME-Version: 1.0 References: <20220516100401.7639-1-ojeda@kernel.org> In-Reply-To: From: Miguel Ojeda Date: Wed, 18 May 2022 15:16:09 +0200 Message-ID: Subject: Re: [PATCH v1] binder: convert `BINDER_*` ioctl `#define`s into an `enum` To: Arnd Bergmann Cc: Miguel Ojeda , Greg Kroah-Hartman , rust-for-linux , Masahiro Yamada , Li Li , Linux Kernel Mailing List , Wedson Almeida Filho Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 18, 2022 at 9:52 AM Arnd Bergmann wrote: > > I wonder if that breaks any tools that extract ioctl command number definitions > from kernel headers. I see one other header using enum, but everything else > has the #define. The main user of ioctl command definitions that comes to > mind is 'strace', but I don't know where they get the numbers from. > > It's probably not a big deal as long as it's limited to binder, but it > may become > more of a problem if we do this for more subsystems over time. Good point. For public headers, we may just want to do this on the Rust side, after all. And it should be as automated as possible too -- I will take a look. In any case, I also took at `strace`. They indeed parse the C files -- with regexes, not an actual C preprocessor/compiler, and for some files, including `binder.h`, they have custom code where they convert the `enum`s into `#define`s and then call the common path on that. But it does that only for `enum`s that match a regexp. So this particular change does not work as-is, though would work if we give a suitable name to the `enum` (I double-checked running the scripts with the changes applied, and it seemed to work). But who knows what other projects are doing anyway, so it may be best to just hold on this change, since anyway Rust Binder is still an RFC -- thus if Linus/Greg decide to merge the Rust support, this change can still wait. And we may not need it anyway if we do it on the Rust side. In conclusion, I would drop this patch for the moment, and I will fix it on our side. (By the way, please note there was a v2: https://lore.kernel.org/lkml/20220517102813.10310-1-ojeda@kernel.org/) Cheers, Miguel