[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72=_UAF5DRHCmW4qNt-Wi3yV6vPEjdLhBTijG_ZGgfpaTA@mail.gmail.com>
Date: Wed, 18 May 2022 15:16:09 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
rust-for-linux <rust-for-linux@...r.kernel.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Li Li <dualli@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Wedson Almeida Filho <wedsonaf@...gle.com>
Subject: Re: [PATCH v1] binder: convert `BINDER_*` ioctl `#define`s into an `enum`
On Wed, May 18, 2022 at 9:52 AM Arnd Bergmann <arnd@...db.de> 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
Powered by blists - more mailing lists