Open ned14 opened 4 years ago
libunifex is only really using the core syscall parts of io_uring and isn't making use of any of the liburing helpers.
However, I have had difficulty trying to just include the platform's linux/io_uring.h header and so have been using the one from liburing as it seems more portable across different sets of linux platform headers. This may just be a shortcoming of trying to use kernel versions and corresponding headers other than the one installed on the distro by default.
I'd be happy to bundle a version of the linux/io_uring.h header that contains the required structs and constants needed for the syscalls. I'll investigate a solution in this direction.
Linux tends to not break kernel ABI, so you can probably safely hard code this stuff into a local header. LLFIO does a ton of that for Windows as we make such extensive use of the NT kernel API. None of those NT kernel APIs have changed since NT 3.5, to my knowledge, though many new ones have been added since.
Right now libunifex includes
io_uring.h
in a public interface header file, and requires cmake targets consuming libunifex to include liburing. liburing is not a commonly installed library, plus it is currently undergoing rapid development, so doing this is somewhat anti-social to quick and easy use of libunifex.Suggested solutions in order of my personal preference:
Personally speaking, I think it is very doable that use of liburing can be kept exclusively internal to source files, and not be required in header files. You just need to reorganise your implementation a bit. Where I'd like to reach is the ability to ship precompiled binaries and a set of headers without imposing extra install steps upon end users.
You can replicate the bare minimum necessary of liburing into public header files, and run a series of static asserts in the source files to ensure that your replicated edition is binary compatible with latest liburing. I've been known to do this in my own code from time to time, and for kernel APIs, maintenance burden is generally excellent.
You can bundle a copy of liburing in with libunifex, either directly as source, or via a git submodule.
Finally, you can leave things as they currently are, where you silently disable io uring support if the end user hasn't installed liburing. I greatly dislike this choice.
This is really a question of direction, which you guys need to choose. I raise this now before we dig a deeper i/o uring packaging hole.