search for: _pread_old

...t count, uint64_t offset); int (*pwrite) (void *handle, const void *buf, uint32_t count, uint64_t offset); int (*flush) (void *handle); int (*trim) (void *handle, uint32_t count, uint64_t offset); int (*zero) (void *handle, uint32_t count, uint64_t offset, int may_trim); +#else + int (*_pread_old) (void *, void *, uint32_t, uint64_t); + int (*_pwrite_old) (void *, const void *, uint32_t, uint64_t); + int (*_flush_old) (void *); + int (*_trim_old) (void *, uint32_t, uint64_t); + int (*_zero_old) (void *, uint32_t, uint64_t, int); +#endif int errno_is_preserved; void (*dump_plugin...

...c_int>, > + > + // Slots for extents functions, which needs more integration. > + _can_extents: Option<extern fn ()>, > + _extents: Option<extern fn ()>, Here, I was just copying what we had already done for the v1 fields that should remain unused (see above, in _pread_old for example). But is there a saner way to write a Rust struct that reserves the space required by the C ABI, but where the field MUST be left as NULL and not populated with Some(...) by the end user? Perhaps by marking the field const, while the rest of the struct is used as a mutable? (Doesn...

...rn fn (*mut c_void) -> c_int>, + pub can_flush: Option<extern fn (*mut c_void) -> c_int>, + pub is_rotational: Option<extern fn (*mut c_void) -> c_int>, + pub can_trim: Option<extern fn (*mut c_void) -> c_int>, + + // Slots for old v1 API functions. + _pread_old: Option<extern fn ()>, + _pwrite_old: Option<extern fn ()>, + _flush_old: Option<extern fn ()>, + _trim_old: Option<extern fn ()>, + _zero_old: Option<extern fn ()>, + + errno_is_preserved: c_int, + + pub dump_plugin: Option<extern fn ()>, + +...

...41,58 @@ extern void nbdkit_set_error (int err); return &(plugin); \ } +#else +#define NBDKIT_REGISTER_PLUGIN(plugin) \ + static int \ + nbdkit_pread_old (void *handle, void *buf, uint32_t count, \ + uint64_t offset) \ + { \ + return (plugin).pread (handle, buf, count, offset, 0); \ + }...

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

I still don't have .prepare/.finalize working cleanly across reopen, but did find a nasty bug where a botched assertion means we failed to notice reads beyond EOF in both the xz and retry filter. Refactoring backend.c will make .finalize work easier. Eric Blake (5): xz: Avoid reading beyond EOF retry: Check size before transactions tests: Test retry when get_size values change

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

...} if (p->plugin.get_size == NULL) { fprintf (stderr, "%s: %s: plugin must have a .get_size callback\n", - program_name, p->filename); + program_name, filename); exit (EXIT_FAILURE); } if (p->plugin.pread == NULL && p->plugin._pread_old == NULL) { fprintf (stderr, "%s: %s: plugin must have a .pread callback\n", - program_name, p->filename); + program_name, filename); exit (EXIT_FAILURE); } - len = strlen (p->plugin.name); - if (len == 0) { - fprintf (stderr, "%s: %s:...

After more than a month since v2 [1], I've finally got my FUA support series polished. This is all of my outstanding patches, even though some of them were originally posted in separate threads from the original FUA post [2], [3] [1] https://www.redhat.com/archives/libguestfs/2018-January/msg00113.html [2] https://www.redhat.com/archives/libguestfs/2018-January/msg00219.html [3]

It's easy to use the sh script to demonstrate that nbdkit is inefficiently calling into .get_size, .can_fua, and friends more than necessary. We've also commented on the list in the past that it would be nice to ensure that when filters call into next_ops, they are not violating constraints (as we've have to fix several bugs in the past where we did not have such checking to protect