mirror of
https://github.com/openharmony/third_party_liburing.git
synced 2026-06-29 20:28:37 -04:00
ohci1
89994945d6
update configure info for 2.14 Created-by: superyang30045862 Commit-by: y30045862;Li Chen;Jens Axboe;Pavel Begunkov;Christian Mazakas;Sebastian Chlad;Yitang Yang;Ryan Northey;Gabriel Krisman Bertazi;Keith Busch;Joshua Rogers;Caleb Sander Mateos;Chris Hofer;Ammar Faizi;Darin Morrison;Romain Pereira;Meiye-lj;Rohan Hendrik Lean;Alviro Iskandar Setiawan;Soham Bagchi;Xianda Ke;Daniel Black;Haiyue Wang;Florian Schmaus;Anuj Gupta;Nitesh Shetty;David Wei;Khem Raj;Sidong Yang;Marcel Holtmann;Jiri Slaby (SUSE);Ronnie Sahlberg;hexue;George Melikov;David Disseldorp;CPestka;Michael de Lang;Jan Hendrik Farr;Ming Lei;Guillem Jover Merged-by: ohci1 Description: update libuirng from 2.7 - 2.14 <!-- Explain your changes here... --> https://dcp.openharmony.cn/workbench/cicd/om-management/dco/detail/139 ---- ## git request-pull output: ``` <!-- START REPLACE ME --> Generate your PR shortlog and diffstat with these commands: git remote add axboe-tree https://github.com/axboe/liburing git fetch axboe-tree git request-pull axboe-tree/master your_fork_URL your_branch_name Then replace this with the output of `git request-pull` command. <!-- END REPLACE ME --> ``` ---- <details> <summary>Click to show/hide pull request guidelines</summary> ## Pull Request Guidelines 1. To make everyone easily filter pull request from the email notification, use `[GIT PULL]` as a prefix in your PR title. ``` [GIT PULL] Your Pull Request Title ``` 2. Follow the commit message format rules below. 3. Follow the Linux kernel coding style (see: https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst). ### Commit message format rules: 1. The first line is title (don't be more than 72 chars if possible). 2. Then an empty line. 3. Then a description (may be omitted for truly trivial changes). 4. Then an empty line again (if it has a description). 5. Then a `Signed-off-by` tag with your real name and email. For example: ``` Signed-off-by: Foo Bar <foo.bar@gmail.com> ``` The description should be word-wrapped at 72 chars. Some things should not be word-wrapped. They may be some kind of quoted text - long compiler error messages, oops reports, Link, etc. (things that have a certain specific format). Note that all of this goes in the commit message, not in the pull request text. The pull request text should introduce what this pull request does, and each commit message should explain the rationale for why that particular change was made. The git tree is canonical source of truth, not github. Each patch should do one thing, and one thing only. If you find yourself writing an explanation for why a patch is fixing multiple issues, that's a good indication that the change should be split into separate patches. If the commit is a fix for an issue, add a `Fixes` tag with the issue URL. Don't use GitHub anonymous email like this as the commit author: ``` 123456789+username@users.noreply.github.com ``` Use a real email address! ### Commit message example: ``` src/queue: don't flush SQ ring for new wait interface If we have IORING_FEAT_EXT_ARG, then timeouts are done through the syscall instead of by posting an internal timeout. This was done to be both more efficient, but also to enable multi-threaded use the wait side. If we touch the SQ state by flushing it, that isn't safe without synchronization. Fixes: https://github.com/axboe/liburing/issues/402 Signed-off-by: Jens Axboe <axboe@kernel.dk> ``` </details> ---- ## By submitting this pull request, I acknowledge that: 1. I have followed the above pull request guidelines. 2. I have the rights to submit this work under the same license. 3. I agree to a Developer Certificate of Origin (see https://developercertificate.org for more information). See merge request: openharmony/third_party_liburing!39
liburing
--------
This is the io_uring library, liburing. liburing provides helpers to setup and
teardown io_uring instances, and also a simplified interface for
applications that don't need (or want) to deal with the full kernel
side implementation.
For more info on io_uring, please see:
https://kernel.dk/io_uring.pdf
Subscribe to io-uring@vger.kernel.org for io_uring related discussions
and development for both kernel and userspace. The list is archived here:
https://lore.kernel.org/io-uring/
kernel version dependency
--------------------------
liburing itself is not tied to any specific kernel release, and hence it's
possible to use the newest liburing release even on older kernels (and vice
versa). Newer features may only be available on more recent kernels,
obviously.
ulimit settings
---------------
io_uring accounts memory it needs under the rlimit memlocked option, which
can be quite low on some setups (64K). The default is usually enough for
most use cases, but bigger rings or things like registered buffers deplete
it quickly. root isn't under this restriction, but regular users are. Going
into detail on how to bump the limit on various systems is beyond the scope
of this little blurb, but check /etc/security/limits.conf for user specific
settings, or /etc/systemd/user.conf and /etc/systemd/system.conf for systemd
setups. This affects 5.11 and earlier, new kernels are less dependent
on RLIMIT_MEMLOCK as it is only used for registering buffers.
Regressions tests
-----------------
The bulk of liburing is actually regression/unit tests for both liburing and
the kernel io_uring support. Please note that this suite isn't expected to
pass on older kernels, and may even crash or hang older kernels!
Building liburing
-----------------
#
# Prepare build config (optional).
#
# --cc specifies the C compiler.
# --cxx specifies the C++ compiler.
#
./configure --cc=gcc --cxx=g++;
#
# Build liburing.
#
make -j$(nproc);
#
# Build liburing.pc
#
make liburing.pc
#
# Install liburing (headers, shared/static libs, and manpage).
#
sudo make install;
See './configure --help' for more information about build config options.
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.
License
-------
All software contained within this repo is dual licensed LGPL and MIT, see
COPYING and LICENSE, except for a header coming from the kernel which is
dual licensed GPL with a Linux-syscall-note exception and MIT, see
COPYING.GPL and <https://spdx.org/licenses/Linux-syscall-note.html>.
Jens Axboe 2022-05-19