search for: myplugin_open

...t name. Note I'm not suggesting that we use this feature in any existing plugins. If we wanted to do this there seem like two possible ways to do it: (1) Add a call, like nbdkit_export_name, which plugins could call from any connected method to get the current export name, eg: static void * myplugin_open (int readonly) { const char *export = nbdkit_export_name (); ... Do something based on the export name ... } The implementation of this is straightforward. It simply reads the exportname global from the server and returns it. It also doesn't change the existing API at all. (2) A better...

...ny > existing plugins. > > If we wanted to do this there seem like two possible ways to do it: at least two ways. > > (1) Add a call, like nbdkit_export_name, which plugins could call from > any connected method to get the current export name, eg: > > static void * > myplugin_open (int readonly) > { > const char *export = nbdkit_export_name (); > > ... Do something based on the export name ... > } I would also consider adding an optional callback: struct nbdkit_export { char *name; size_t size; // maybe other fields for supporting NBD_OPT_INFO......

...ot;myplugin\0" as *const str as *const [c_char] as *const c_char; - // Create a mutable plugin, setting the 5 required fields. + // Create a mutable plugin, setting the 4 required fields. let mut plugin = Plugin::new ( - Serialize_All_Requests, name, myplugin_open, myplugin_get_size, @@ -53,6 +58,7 @@ compatible with the C struct used by C plugins. // Update any other fields as required. plugin.close = Some (myplugin_close); plugin.pwrite = Some (myplugin_pwrite); + plugin.thread_model = Some (myplugin_thread_model); // Retur...

...it-ocaml-plugin.pod b/plugins/ocaml/nbdkit-ocaml-plugin.pod index a66cf26e..4b349612 100644 --- a/plugins/ocaml/nbdkit-ocaml-plugin.pod +++ b/plugins/ocaml/nbdkit-ocaml-plugin.pod @@ -36,12 +36,11 @@ Your OCaml code should call C<NBDKit.register_plugin> like this: open_connection = Some myplugin_open; get_size = Some myplugin_get_size; pread = Some myplugin_pread; + thread_model = Some (fun () -> NBDKit.THREAD_MODEL_SERIALIZE_CONNECTIONS); (* etc *) } - let thread_model = NBDKit.THREAD_MODEL_SERIALIZE_CONNECTIONS - - let () = NBDKit.register_pl...

...t str as *const [c_char] as *const c_char; > > - // Create a mutable plugin, setting the 5 required fields. > + // Create a mutable plugin, setting the 4 required fields. > let mut plugin = Plugin::new ( > - Serialize_All_Requests, > name, > myplugin_open, > myplugin_get_size, > @@ -53,6 +58,7 @@ compatible with the C struct used by C plugins. > // Update any other fields as required. > plugin.close = Some (myplugin_close); > plugin.pwrite = Some (myplugin_pwrite); > + plugin.thread_model = Some (myplugin...

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

A common idiom where we don't need a per-connection handle is: static void * myplugin_open (int readonly) { static int handle; return &handle; } We need to return some non-NULL value, but we don't care what. This commit defines a macro NBDKIT_HANDLE_NOT_NEEDED which contains a meaningless non-NULL pointer which can be used instead of the above. This is more descript...

...-> *const Plugin { + // Plugin name. + let name = "myplugin\0" + as *const str as *const [c_char] as *const c_char; + + // Create a mutable plugin, setting the 5 required fields. + let mut plugin = Plugin::new ( + Serialize_All_Requests, + name, + myplugin_open, + myplugin_get_size, + myplugin_pread + ); + // Update any other fields as required. + plugin.close = Some (myplugin_close); + plugin.pwrite = Some (myplugin_pwrite); + + // Return the pointer. + let plugin = Box::new(plugin); + return Box::into_raw(plugin); +} +...

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