search for: threadmodel

Similar to what I just did for OCaml (this IS an API break, requiring recompilation of any existing Rust plugin), and done because I want to add fast_zero support to both languages as part of my upcoming fast zero series. Figuring out how to get extents working was hard enough that I punted that, still. Eric Blake (2): rust: Implement can_cache rust: Add support for dynamic .thread_model

.... Since all existing Rust plugins will have already thought about thread models, they can convert their existing model into the new .thread_model field (and thus, I don't feel too bad making Parallel the default, even if it is not always the safest). And something I learned the hard way: enum ThreadModel _must_ be #[repr(C)], otherwise Rust will compile a return type of this enum into a 1-byte return, even though C expects sign-extension into a 4-byte return; the garbage left in the other three bytes (at least on x86 architecture) would generally render .thread_model broken otherwise. Signed-off-b...

...t plugins will have already thought about thread > models, they can convert their existing model into the new > .thread_model field (and thus, I don't feel too bad making Parallel > the default, even if it is not always the safest). > > And something I learned the hard way: enum ThreadModel _must_ be > #[repr(C)], otherwise Rust will compile a return type of this enum > into a 1-byte return, even though C expects sign-extension into a > 4-byte return; the garbage left in the other three bytes (at least on > x86 architecture) would generally render .thread_model broken >...

...ted to emulating TLS? So I look into the IR file but noticed that these function where not mentioned there. So I assumed they must be created by the JIT process, so I went there and looked for my "llvm::TargetOptions" and set these values explicit: options.ThreadModel = llvm::ThreadModel::Single; options.EmulatedTLS = false; options.ExplicitEmulatedTLS = false; Sadly this didn't changed a thing... Also setting "-Xclang -fno-emulated-tls" didn't worked, only setting the MSVC switch...

...OTHERWISE) ARISING IN ANY WAY OUT +// OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +// SUCH DAMAGE. + +extern crate nbdkit; + +#[macro_use] +extern crate lazy_static; + +use libc::*; +use std::ptr; +use std::os::raw::c_int; +use std::sync::Mutex; + +use nbdkit::*; +use nbdkit::ThreadModel::*; + +// The RAM disk. +lazy_static! { + static ref DISK: Mutex<Vec<u8>> = Mutex::new (vec![0; 100 * 1024 * 1024]); +} + +struct Handle { + // Box::new doesn't allocate anything unless we put some dummy + // fields here. In a real implementation you would put per-handle +...

...tents: Option<extern fn ()>, + + pub can_cache: Option<extern fn (h: *mut c_void) -> c_int>, + pub cache: Option<extern fn (h: *mut c_void, + count: u32, offset: u64, + flags: u32) -> c_int>, } pub enum ThreadModel { @@ -146,6 +155,10 @@ impl Plugin { zero: None, magic_config_key: std::ptr::null(), can_multi_conn: None, + _can_extents: None, + _extents: None, + can_cache: None, + cache: None, } } } -- 2.20.1

This adds very rough support for writing nbdkit plugins in Rust. This is not very idiomatic -- essentially we're handling the direct C calls from nbdkit in Rust. We have to use ‘unsafe’ in a few places because there's no way to tell the Rust code that nbdkit satisfies guarantees (eg. around thread safety, always returning leaked pointers back to the close function, always doing bounds

There are few more things that could be cleaned up related to the coding style and other things, like explicitly specifying the abi style after "extern" (i.e. `extern "C" fn` instead of `extern fn`), but since those are configurable in rustfmt config, I'm not sure whether the config needs to be added or complying with the defaults should be the priority. But this was just

...al/include -I/opt/BOOST/include -std=c++14-D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS ../../../src/contrib/'contribJIT'.'cpp'-o 'contribJIT'.o `/usr/local/bin/llvm-config --cppflags``;cd ..;fi clang version 4.0.1(tags/RELEASE_401/final)Target:x86_64-unknown-linux-gnu Threadmodel:posix InstalledDir:/usr/local/bin Foundcandidate GCC installation:/usr/lib/gcc/x86_64-linux-gnu/6Foundcandidate GCC installation:/usr/lib/gcc/x86_64-linux-gnu/6.3.0SelectedGCC installation:/usr/lib/gcc/x86_64-linux-gnu/6.3.0Candidatemultilib:.;@m64Selectedmultilib:.;@m64"/usr/local/bin/clan...

...a/plugins/rust/src/lib.rs b/plugins/rust/src/lib.rs index 53619dd9..313b4ca6 100644 --- a/plugins/rust/src/lib.rs +++ b/plugins/rust/src/lib.rs @@ -105,6 +105,8 @@ pub struct Plugin { flags: u32) -> c_int>, pub thread_model: Option<extern fn () -> ThreadModel>, + + pub can_fast_zero: Option<extern fn (h: *mut c_void) -> c_int>, } #[repr(C)] @@ -163,6 +165,7 @@ impl Plugin { can_cache: None, cache: None, thread_model: None, + can_fast_zero: None, } } } diff --git a/tests/t...

I will be following up to this email with four separate threads each addressed to the appropriate single list, with proposed changes to: - the NBD protocol - qemu: both server and client - libnbd: client - nbdkit: server The feature in question adds a new optional NBD_INFO_ packet to the NBD_OPT_GO portion of handshake, adding up to 16 bits of information that the server can advertise to the

This is a cover letter to a series of patches being proposed in tandem to four different projects: - nbd: Document a new NBD_CMD_FLAG_FAST_ZERO command flag - qemu: Implement the flag for both clients and server - libnbd: Implement the flag for clients - nbdkit: Implement the flag for servers, including the nbd passthrough client If you want to test the patches together, I've pushed a