On Thu, Jun 06, 2024 at 12:00:36PM -0700, Boqun Feng wrote:
On Thu, Jun 06, 2024 at 07:35:44PM +0200, Peter Zijlstra wrote:
quoted
On Thu, Jun 06, 2024 at 08:49:06AM -0700, Boqun Feng wrote:
quoted
Long-term plan is to 1) compile the C helpers in some IR and 2) inline
the helpers with Rust in IR-level, as what Gary has:
https://lore.kernel.org/rust-for-linux/20240529202817.3641974-1-gary@garyguo.net/ (local)
Urgh, that still needs us to maintain that silly list of helpers :-/
But it's an improvement from the current stage, right? ;-)
Somewhat, but only marginal.
quoted
Can't we pretty please have clang parse the actual header files into IR
and munge that into rust? So that we don't get to manually duplicate
everything+dog.
That won't always work, because some of our kernel APIs are defined as
macros, and I don't think it's a trivial job to generate a macro
definition to a function definition so that it can be translated to
something in IR. We will have to do the macro -> function mapping
ourselves somewhere, if we want to inline the API across languages.
We can try and see how far we can get with moving a bunch of stuff into
inlines. There's quite a bit of simple CPP that could be inlines or
const objects I suppose.
Things like the tracepoints are of course glorious CPP abuse and are
never going to work.
But perhaps you can have an explicit 'eval-CPP on this here' construct
or whatnot. If I squit I see this paste! thingy (WTF's up with that !
operator?) to munge function names in the static_call thing. So
something like apply CPP from over there on this here can also be done
:-)