liburing-ffi headers

[ghost]

im linking to liburing-ffi.a
you says that

Users wishing to consume liburing purely as a binary dependency
should link against liburing-ffi. It contains definitions for every 'static
inline' function.

im using rustbindgen to generate rust definition of c headers
but rustbindgen cannot handle inline functions
i need liburing-ffi.h instead of liburing.h

changed
rustbindgen can handle static inline

[ghost]

@axboe there's two libraries "liburing.a" and "liburing-ffi.a",but
there's only one header. It makes no sense

[ghost]

@cmazakas

[ghost]

is ffi varient just -fno-inline-functions
What's the difference

[ammarfaizi2]

Languages and applications that can't use 'static inline' functions in
liburing.h should use the FFI variants.

If you can use the header, then there is no point in using FFI.

The FFI version is supposed to be used by programming languages that
can't use the liburing.h header. IOW, other than the C/C++ language.

[ghost]

how do i get metadata without header

[ghost]

I don't even know the signature of the function because there is no header
In other words, how do I create function signatures in other languages ​​without C header

[ammarfaizi2]

I don't even know the signature of the function because there is no header

The signature doesn't change; still the same as the non-FFI version.

What programming language are you working on?

[ammarfaizi2]

In other words, how do I create function signatures in other languages ​​without C header

Use the same signature as the non-FFI version.

[ghost]

im using rustbindgen to generate rust definition of c headers
but rustbindgen cannot handle inline functions

Does it mean that if liburing-ffi.h exists, just delete all static inline and function body?

[ammarfaizi2]

Does it mean that if liburing-ffi.h exists, just delete all static inline and function body?

Yes, exactly.

[ghost]

rustbindgen is an automated tool to generate rust bindings from c language headers, I don't like manual bindings because manual is fragile and complicated

[ghost]

I mean liburing-ffi.h is needed because the existing C header files are not suitable for rustbindgen or similar automation tools, and this may make things less complicated

[ammarfaizi2]

I don't know about rustbindgen, but from a quick google, I found this:

rust-lang/rust-bindgen#2335

Does that solve your problem?

[ghost]

I tried, it didn't help, it just made things more complicated

[ghost]

Link time optimization should be able to ignore static inline

[ghost]

The header file is static inline, but the binary is an normal function, I am curious how this is done

[ammarfaizi2]

The header file is static inline, but the binary is an normal function, I am curious how this is done

All static inline definitions in the header use the IOURINGINLINE macro.

In the FFI version, we get rid of those static inline marks
by defining the macro as an empty macro like this:

#define IOURINGINLINE

It's defined in:
https://github.com/axboe/liburing/blob/master/src/ffi.c

The ffi.c is what liburing-ffi.a and liburing-ffi.so are made of.

[ammarfaizi2]

Looking at your case where other languages can generate the binding
from the C header file. I think it's reasonable to create liburing-ffi.h.

[ghost]

If IOURINGINLINE is empty, isn't the function body redundant?
Will the code compile？
I only need to define IOURINGINLINE to be empty to create liburing-ffi.h?

[ghost]

I found that I know little about C language

[ammarfaizi2]

If IOURINGINLINE is empty, isn't the function body redundant?

No, the body is not redundant. If IOURINGINLINE is empty, the body
will be included in the binary file. The compiler is not allowed to
remove the functions. That's when FFI.

If IOURINGINLINE is static inline, the function is allowed to be
completely removed if not used at compile time. That is when we use C/C++.

Will the code compile？

Obviously, that's how the current FFI binaries are made.

I only need to define IOURINGINLINE to be empty to create liburing-ffi.h?

You need to remove the body as well.

The original liburing.h is still needed to create the FFI binaries
because the function body is there.

[ghost]

Perhaps the c header is not suitable for ffi. Perhaps XML should be used to describe metadata. That's what vulkan does, and so does the Windows api

[alviroiskandar]

I tried, it didn't help, it just made things more complicated

Can you expand on that? Why it made things more complicated?

I can easily generate the binding this way:

bindgen --experimental --wrap-static-fns src/include/liburing.h --wrap-static-fns-suffix="" -o q.rs

and get all io_uring static inline function signatures:
https://gist.github.com/alviroiskandar/be31d247d8e152913ba38465e5e44883

[ghost]

I don't like experimental, and it's the equivalent of translating c to rust, which isn't ffi at all

changed
it's my fault

[cmazakas]

I actually just mantain the bindings by hand in Rust, I don't like bindgen exactly for the reasons discovered in this issue.

liburing's API even includes macros. bindgen is good for simple tools but in general, it's more robust to own your own declarations from Rust.

[ghost]

I seem to have solved it, renamed ffi.c to ffi.h, bindgen ffi.h -o bindings.rs

[ghost]

Tested and it works

I seem to have solved it, renamed ffi.c to ffi.h, bindgen ffi.h -o bindings.rs

[ghost]

miniuring on crates.io

[ghost]

@cmazakas

[alviroiskandar]

I don't like experimental

This is actually not a liburing problem. Any language that opt in to use liburing FFI should provide their way to connect with liburing-ffi, not the other way around. bindgen and what @cmazakas does are the examples of it.

and it's the equivalent of translating c to rust

Only the signatures. Not the body.

which isn't ffi at all

That's FFI, the functions are still defined in liburing-ffi.so and liburing-ffi.a. --wrap-static-fns doesn't convert the function body to Rust. It converts the C function signatures to Rust, not the body.

I seem to have solved it, renamed ffi.c to ffi.h, bindgen ffi.h -o bindings.rs

BTW, the rename is not necessary, the following also works:

bindgen src/ffi.c -o bindings.rs

It generates exactly the same binding as the experimental feature except that it doesn't have something like

#[link_name = "io_uring_prep_readv"]

[ghost]

you are right