Use LOOP_CONFIGURE ioctl for attaching to loop devices #57
Conversation
This ioctl was added to Linux[0] as a faster and atomic alternative to the combination of LOOP_SET_FD and LOOP_SET_STATUS. In order to support older kernels, the function will still fallback to those syscalls if necessary. [0]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=3448914e8cc550ba792d4ccc74471d1ca4293aae
| @@ -38,8 +38,8 @@ | |||
| //! ld.detach().unwrap(); | |||
| //! ``` | |||
| use crate::bindings::{ | |||
| loop_info64, LOOP_CLR_FD, LOOP_CTL_GET_FREE, LOOP_SET_CAPACITY, LOOP_SET_FD, LOOP_SET_STATUS64, | |||
| LO_FLAGS_AUTOCLEAR, LO_FLAGS_PARTSCAN, LO_FLAGS_READ_ONLY, | |||
| loop_config, loop_info64, LOOP_CLR_FD, LOOP_CONFIGURE, LOOP_CTL_GET_FREE, LOOP_SET_CAPACITY, | |||
There was a problem hiding this comment.
Using LOOP_CONFIGURE will cause problems with toolchains that do not contain that define and the libc headers are generated from a kernel prior LOOP_CONFIGURE. The devicemapper crate had similar problems with features added over the years.
LOOP_CONFIGURE is great but must be guarded by a feature.
I'm not sure if it's possible to reliably detect the kernel, libc header version etc... from a build.rs.
There was a problem hiding this comment.
Just checked a build for aarch64-linux-android with cross:
~/loopdev ‹loop-configure› cross build --target=aarch64-linux-android
Compiling memchr v2.5.0
Compiling glob v0.3.0
Compiling libc v0.2.137
Compiling proc-macro2 v1.0.47
Compiling minimal-lexical v0.2.1
Compiling quote v1.0.21
Compiling cfg-if v1.0.0
Compiling unicode-ident v1.0.5
Compiling bindgen v0.60.1
Compiling regex-syntax v0.6.27
Compiling lazycell v1.3.0
Compiling bitflags v1.3.2
Compiling shlex v1.1.0
Compiling peeking_take_while v0.1.2
Compiling rustc-hash v1.1.0
Compiling lazy_static v1.4.0
Compiling libloading v0.7.3
Compiling clang-sys v1.4.0
Compiling nom v7.1.1
Compiling errno v0.2.8
Compiling regex v1.6.0
Compiling cexpr v0.6.0
Compiling loopdev v0.5.0 (/project)
error[E0432]: unresolved imports `crate::bindings::loop_config`, `crate::bindings::LOOP_CONFIGURE`
--> src/lib.rs:41:5
|
41 | loop_config, loop_info64, LOOP_CLR_FD, LOOP_CONFIGURE, LOOP_CTL_GET_FREE, LOOP_SET_CAPACITY,
| ^^^^^^^^^^^ ^^^^^^^^^^^^^^ no `LOOP_CONFIGURE` in `bindings`
| |
| no `loop_config` in `bindings`
For more information about this error, try `rustc --explain E0432`.
error: could not compile `loopdev` due to previous error
I don't know the exact version of the libc headers used in the NDK here but it's notorious outdated ;-)
| return Err(err); | ||
| } | ||
| retries += 1; | ||
| sleep(Duration::from_micros(25000)); |
There was a problem hiding this comment.
Is there a specific reason the value?
Depending on the use case 25ms can be in acceptable long time.
|
I implemented a kernel version check and depending on the result a feature https://github.com/flxo/loopdev/tree/loop-configure The most interesting part is that the binding generation must be moved in to a |
|
FYI. Rebased the POC. |
This ioctl was added to Linux0 as a faster and atomic alternative to the combination of LOOP_SET_FD and LOOP_SET_STATUS. In order to support older kernels, the function will still fallback to those syscalls if necessary.
The
attach_a_backing_file_with_part_scan_defaulttest passed, and I verified the functionality in my project that uses this crate. I was only able to test on a recent kernel:straceconfirmed that the new ioctl was being used.I can build an old kernel to try the fallback behavior, but I have not made time for that yet.