[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=MXHZ2XswxkfzLqUEPwriNy=_sxAQpOYoYW8iNgyuJ8Q@mail.gmail.com>
Date: Sun, 23 Nov 2025 18:07:54 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: David Gow <davidgow@...gle.com>
Cc: Richard Weinberger <richard@....at>, Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Johannes Berg <johannes@...solutions.net>, Miguel Ojeda <ojeda@...nel.org>,
"Paolo 'Blaisorblade' Giarrusso" <blaisorblade@...oo.it>, Alice Ryhl <aliceryhl@...gle.com>,
linux-um@...ts.infradead.org, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH] arch: um: Don't rename vmap to kernel_vmap
On Sat, Nov 22, 2025 at 9:32 AM David Gow <davidgow@...gle.com> wrote:
>
> In order to work around the existence of a vmap symbol in libpcap, the
> UML makefile unconditionally redefines vmap to kernel_vmap. However,
> this not only affects the actual vmap symbol, but also anything else
> named vmap, including a number of struct members in DRM.
>
> This would not be too much of a problem, since all uses are also
> updated, except we now have Rust DRM bindings, which expect the
> corresponding Rust structs to have 'vmap' names. Since the redefinition
> applies in bindgen, but not to Rust code, we end up with errors such as:
>
> error[E0560]: struct `drm_gem_object_funcs` has no fields named `vmap`
> --> rust/kernel/drm/gem/mod.rs:210:9
>
> Since, as far as I can tell, we no longer actually link to libpcap, it
> should be safe to just remove this define unconditionally.
>
> (If it's not, we can possibly either disable DRM Rust bindings under
> UML, or move the redefinition of vmap behind some config option.)
>
> We also take this opportunity to update the comment.
>
> Signed-off-by: David Gow <davidgow@...gle.com>
Nice, thanks for this!
Yeah, I guess we would otherwise need to do the same kind of "wild"
macro replacement in Rust code to support this or conditional
compilation, and neither sounds good.
If it is not actually needed, then this sounds like a win-win.
It seems it was indeed gone in commit:
12b8e7e69aa7 ("um: Remove obsolete pcap driver")
So it sounds reasonable to me assuming I am not missing anything,
which I may be... FWIW:
Acked-by: Miguel Ojeda <ojeda@...nel.org>
Cheers,
Miguel
Powered by blists - more mailing lists