What exactly is this liburing-ffi, how does one go about using it?

[YoSTEALTH]

What exactly is this liburing-ffi, how does one go about using it? Is there some advantage in using liburing.so vs liburing-ffi.so?

[ammarfaizi2]

Hi,

What exactly is this liburing-ffi, how does one go about using it?

The README file in the repo has explained it:

FFI support
-----------

By default, the build results in 4 lib files:

    2 shared libs:

        liburing.so
        liburing-ffi.so

    2 static libs:

        liburing.a
        liburing-ffi.a

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

liburing's main public interface lives in liburing.h as 'static inline'
functions. Users wishing to consume liburing purely as a binary dependency
should link against liburing-ffi. It contains definitions for every 'static
inline' function.

Is there some advantage in using liburing.so vs liburing-ffi.so?

• liburing.so is smaller than liburing-ffi.so.
• The usage of the 'static inline' functions elides the function call overhead (this is only usable from C and C++).

[ammarfaizi2]

I am not sure, I don't see much of a difference between the two, after compiled the file sizes are 5-10MB.

I didn't say the difference is much, though.

Also not sure what this liburing-ffi.map file is about!

liburing-ffi.map contains 'static inline' functions while liburing.map doesn't.

[axboe]

It's not mostly about sizing, it's about how you can use it. @ammarfaizi2 already talked about that, but the gist of it is that if you have a C/C++ application, then you can use the static inline helpers that are in liburing.h. For other languages, that's not so easy. And rather than have them re-implement all their own prep or whatever helpers internally, which is both duplication and error prone, it's much easier to use the ffi as they are all exported helpers. For C/C++ you don't want to use the ffi, as it would just be an extra function call for every one.

[YoSTEALTH]

I feel like you have done some amazing work to provide ffi features. I am trying to use it and not waste it.

That being said, ffi normally has a lot of limitations, for example:

• If I parse .map file to include functions
  -- Types and arguments still needs to be defined manually.
  -- Defines and Enum and such still needs to be defined manually.
  -- Any ffi that auto includes such things normally tends to be really slow.
• I can use inline functions but not static inline

You can see how other language would wrap liburing here https://github.com/YoSTEALTH/Liburing/tree/master/src/liburing (work still in progress and a mess for now.)

Once the work is mostly stable, maybe I can do a benchmark liburing.so vs liburing-ffi.so to see if there is some performance improvement.

[cmazakas]

Originally, I just wanted to use liburing from Rust but I ran into a lot of issues with that.

Having a defined set of exports made it easier to write idiomatic liburing code without the need to manually reimplement the entire vocabulary. liburing's main draw, imo, is that it gives consumers a well-defined vocabulary to use.

[YoSTEALTH]

@cmazakas Nice. If I use the .map to auto create ffi, the end result will be much slower, not sure how it is with Rust. Of course writing software where you can tweak a lot has its own advantage, but more coding. For now I am going to wrap it around ffi-liburing.so and see if static inline part kicks in.