Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bindgen wanted features & bugfixes #353

Open
20 of 27 tasks
ojeda opened this issue Jun 4, 2021 · 12 comments
Open
20 of 27 tasks

bindgen wanted features & bugfixes #353

ojeda opened this issue Jun 4, 2021 · 12 comments
Labels
meta Meta issue. • toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy...

Comments

@ojeda
Copy link
Member

ojeda commented Jun 4, 2021

Note: see as well the "rust-for-linux" label in bindgen: https://github.com/rust-lang/rust-bindgen/labels/rust-for-linux.

Features that we would like to see

Required (we almost certainly want them)

Nice to have (not critical, we could workaround if needed, etc.)

Low priority (we will likely not use them in the end)

Done (stabilized, fixed, not needed anymore, etc.)


Bugs that we would like to see fixed

Required (we almost certainly want them)

Nice to have (probably not critical, we could workaround if needed, etc.)

Low priority (we will likely not use them in the end)

Done (stabilized, fixed, or not needed anymore, etc.)

@ojeda ojeda added • toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy... meta Meta issue. labels Jun 4, 2021
@ojeda ojeda changed the title bindgen wanted features bindgen wanted features & bugfixes Jun 4, 2021
@pvdrz
Copy link

pvdrz commented Sep 15, 2022

Hi everyone!

I have opened some PRs on bindgen adding some features you needed:

I'd be happy to hear if the PRs here actually provide what you need.

@alex
Copy link
Member

alex commented Sep 15, 2022

These look spot on to me. Thanks for your efforts!

@ojeda
Copy link
Member Author

ojeda commented Sep 22, 2022

Added links above, thanks a lot @pvdrz! :)

@dwlsalmeida
Copy link

@ojeda Hey Miguel, is there a workaround in place for this?

Support function-like macros that use other macros and that evaluate to a numeric value when fully expanded (e.g. for Linux ioctl #defines using _IO*).

I am trying to write a v4l2 driver and one of the issues I found was that the pixel formats bindings are not generated by bindgen because the V4L2_PIX_FMT_* stuff is defined using the v4l2_fourcc macro

@ojeda
Copy link
Member Author

ojeda commented Jan 16, 2023

For something like pixel formats that are stable (given they are in uapi, right?), I guess the easiest is re-implementing them on the Rust side, especially if you want to give them a proper type etc. anyway. Probably using a small temporary script to perform the bulk of the conversion.

Otherwise, if performance is not too much of a concern (even if cross-language LTO could reduce the cost at some point), one alternative is "executing" the macro at runtime by providing a C function that does it for the Rust side. In your case this one is likely not interesting because the important bits are the parameters to the macro, rather than the macro itself.

@bjorn3
Copy link
Member

bjorn3 commented Jan 16, 2023

For the drm fourcc pixel format codes, the drm-fourcc crate has some code which fetches all #define from the header, generates a constant for each #define in a new header and then runs bindgen on the generated header: https://github.com/danielzfranklin/drm-fourcc-rs/blob/main/build.rs

@dwlsalmeida
Copy link

One question though, suppose I use the approach suggested by @bjorn3

Do I commit the bindings I generate? Asking because apparently bindings_generated.rs is not part of the kernel per-se and is only generated during build time.

@bjorn3
Copy link
Member

bjorn3 commented Jan 16, 2023

I think the bindings should be generated on the fly to ensure they stay up to date, just like bindings_generated.rs.

@dwlsalmeida
Copy link

well, in which case I suppose that the code to generate them (i.e. something similar to the code in the drm-fourcc crate) would have to be integrated into the kernel build system somehow?

@bjorn3
Copy link
Member

bjorn3 commented Jan 16, 2023

Indeed. There is already infrastructure to run code written in rust. See for example scripts/generate_rust_target.rs.

@dwlsalmeida
Copy link

Makes sense, thanks for the pointers!

@ojeda
Copy link
Member Author

ojeda commented Jan 16, 2023

It depends. If these constants are strictly stable (unlike many kernel APIs that you may see in bindings_generated.rs), you have the possibility to commit them, but in that case I would recommend writing directly in Rust what you need (rather than raw bindings that then you wrap). This is why I mentioned above the stability. You could also have a test to verify both sides match, though that could be a one-off thing.

If you go the generated route (which many times is the only way), then indeed, you could use a host program (it does not necessarily need to be written in Rust, but as @bjorn3 mentions, the support is there, so I would recommend it -- though currently you will only have the Rust standard library available, e.g. no regex). This approach has the drawback of adding complexity (the host program) and, depending on how you implement/parse the C header, you may introduce constraints on the C side. Another similar option is a proc macro, but that is slower (triggered every time you recompile the kernel crate, which would be unneeded -- you only need to do it once) and non-"pure" (in the "do not use the environment from a proc macro" sense).

Another angle to think about is whether new constants will appear frequently or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Meta issue. • toolchain Related to `rustc`, `bindgen`, `rustdoc`, LLVM, Clippy...
Development

No branches or pull requests

5 participants