search for: plugin_init

We do not promise API stability for non-C languages; this is an API break as follows: instead of calling plugin_init with a static model, you can now populate .thread_model in the Plugin struct, with a default to Parallel. As in C, the model is still chosen at .load time (at most, making it a function allows you to alter it based on configuration), and not something that can change per-connection. Since all exi...

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

On Fri, Aug 16, 2019 at 12:08:11PM -0500, Eric Blake wrote: > We do not promise API stability for non-C languages; this is an API > break as follows: instead of calling plugin_init with a static model, > you can now populate .thread_model in the Plugin struct, with a > default to Parallel. As in C, the model is still chosen at .load time > (at most, making it a function allows you to alter it based on > configuration), and not something that can change per-connec...

Hi All. I am developing plugin for Dovecot. And I needs for read some configuration file at startup and store configuration in application wide variable. As I see the plugin_init() method calls multiple times and allocates plugin's variables each time. Could you suggest better way to store variable in application context. Thank you Valery Gorbunov

...opened"); exit (EXIT_FAILURE); } +#ifdef WINDOWS_COMPAT + init_functions (); +#endif #if !ENABLE_LIBFUZZER threadlocal_init (); @@ -772,6 +819,7 @@ open_plugin_so (size_t i, const char *name, int short_name) bool free_filename = false; void *dl; struct nbdkit_plugin *(*plugin_init) (void); + void *(*functions_init) (struct nbdkit_functions *); char *error; if (short_name) { @@ -797,6 +845,18 @@ open_plugin_so (size_t i, const char *name, int short_name) /* Initialize the plugin. See dlopen(3) to understand C weirdness. */ dlerror (); +#ifdef WINDOWS_COMPAT...

...#define CLEANUP_FREE __attribute__((cleanup (cleanup_free))) @@ -142,28 +144,31 @@ extern int crypto_negotiate_tls (struct connection *conn, int sockin, int sockou #define debug nbdkit_debug /* plugins.c */ -extern void plugin_register (const char *_filename, void *_dl, struct nbdkit_plugin *(*plugin_init) (void)); -extern void plugin_cleanup (void); -extern int plugin_thread_model (void); -extern const char *plugin_name (void); -extern void plugin_usage (void); -extern const char *plugin_version (void); -extern void plugin_dump_fields (void); -extern void plugin_config (const char *key, const char...

...#define CLEANUP_FREE __attribute__((cleanup (cleanup_free))) @@ -142,28 +150,31 @@ extern int crypto_negotiate_tls (struct connection *conn, int sockin, int sockou #define debug nbdkit_debug /* plugins.c */ -extern void plugin_register (const char *_filename, void *_dl, struct nbdkit_plugin *(*plugin_init) (void)); -extern void plugin_cleanup (void); -extern int plugin_thread_model (void); -extern const char *plugin_name (void); -extern void plugin_usage (void); -extern const char *plugin_version (void); -extern void plugin_dump_fields (void); -extern void plugin_config (const char *key, const char...

...#define CLEANUP_FREE __attribute__((cleanup (cleanup_free))) @@ -142,28 +150,31 @@ extern int crypto_negotiate_tls (struct connection *conn, int sockin, int sockou #define debug nbdkit_debug /* plugins.c */ -extern void plugin_register (const char *_filename, void *_dl, struct nbdkit_plugin *(*plugin_init) (void)); -extern void plugin_cleanup (void); -extern int plugin_thread_model (void); -extern const char *plugin_name (void); -extern void plugin_usage (void); -extern const char *plugin_version (void); -extern void plugin_dump_fields (void); -extern void plugin_config (const char *key, const char...

...quot; > +authors = ["Richard W.M. Jones <rjones@redhat.com>"] > +edition = "2018" 2019? Some form of @YEAR@ to make it auto-update from configure results? > +++ b/plugins/rust/examples/ramdisk.rs > + > +// Every plugin must define a public, C-compatible plugin_init > +// function which returns a pointer to an Plugin struct. s/an Plugin/a Plugin/ Otherwise, it seems to work (given my lack of Rust knowledge) -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

Somewhat invasive but mostly mechanical change to how plugins are called. This patch is in preparation for adding a second backend subtype for filters. Rich.

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

...> c_int { + let offset = offset as usize; + let count = count as usize; + let mut disk = DISK.lock().unwrap(); + unsafe { + ptr::copy_nonoverlapping (buf as *const u8, &mut disk[offset], count); + } + return 0; +} + +// Every plugin must define a public, C-compatible plugin_init +// function which returns a pointer to an Plugin struct. +#[no_mangle] +pub extern fn plugin_init () -> *const Plugin { + // Plugin name. + // https://github.com/rust-lang/rfcs/issues/400 + let name = "ramdisk\0" as *const str as *const [c_char] as *const c_char; + + // Cr...

v1 -> v2: - Fixed everything mentioned in the review. Rich.

On 8/18/20 8:53 AM, Richard W.M. Jones wrote: > On Tue, Aug 18, 2020 at 07:48:43AM -0500, Eric Blake wrote: >>> +extern int nbdkit_main (int argc, char *argv[]); >> >> A bit odd to declare this in a .c; but I don't see any existing >> decent .h to put it in, nor is it worth adding a new one just for >> this. So it is fine right here. > > Yup, better

...nd *); const char *(*name) (struct backend *); @@ -175,7 +188,11 @@ struct backend { int (*zero) (struct backend *, struct connection *conn, uint32_t count, uint64_t offset, int may_trim); }; -extern struct backend *plugin_register (const char *_filename, void *_dl, struct nbdkit_plugin *(*plugin_init) (void)); +/* plugins.c */ +extern struct backend *plugin_register (size_t index, const char *filename, void *dl, struct nbdkit_plugin *(*plugin_init) (void)); + +/* filters.c */ +extern struct backend *filter_register (struct backend *next, size_t index, const char *filename, void *dl, struct nbdk...

I pushed a few of the msys2 patches upstream. I changed the way that $(SHARED_LDFLAGS) works so it's more to my liking, and the others were pushed unchanged. Three patches remain which I'm posting on the mailing list for proper review. Rich.

...heck that golang >= 1.5 since that was the first version that introduced shared libraries. - Since initialization is not synchronous in golang, you cannot rely on anything being initialized in the plugin before nbdkit starts calling in. For this reason I worked around it by having plugin_init() call a start up function (func init_plugin()) where all golang initialization must be done. Otherwise: nbdkit: golang plugin: dlopen ("plugin.so"); let's start initializing init = dlsym ("pl...

v1 was here: https://www.redhat.com/archives/libguestfs/2019-November/msg00003.html This version depends on: https://www.redhat.com/archives/libguestfs/2019-November/msg00004.html and this series: https://www.redhat.com/archives/libguestfs/2019-November/msg00009.html The delta has been reduced slightly because of changes made possible by cleaning up and fixing the quit path in nbdkit. It's

libFuzzer is Clang's fuzzer, and alternative to using AFL: https://llvm.org/docs/LibFuzzer.html I implemented an alternative method of fuzzing for libnbd earlier today and it's pretty simple: https://github.com/libguestfs/libnbd/commit/c19a6fbae9a21a7d4693418706c59e81ed256875 However it's considerably more difficult to use libFuzzer with non-library code -- in this case nbdkit.

...;calling nbdkit_debug now ..."); } and on loading this plugin into server/nbdkit.exe: nbdkit_parse_int addr = 000000000040BD40 nbdkit: debug: calling nbdkit_debug now ... So it really does work. I'm not quite sure exactly how to integrate this. Perhaps adding some Windows-only code to plugin_init which does the appropriate GetProcAddress calls, initializing some function pointers in the plugin? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from s...