search for: nbdkit_block_size_get_max_zero

...hich means we should be thinking about supporting future protocol extensions in whatever we expose to plugins. So, I'm thinking something like the following: New enum: NBDKIT_BLOCK_SIZE_GET_MINIMUM NBDKIT_BLOCK_SIZE_GET_PREFERRED NBDKIT_BLOCK_SIZE_GET_MAX_DATA NBDKIT_BLOCK_SIZE_GET_MAX_TRIM NBDKIT_BLOCK_SIZE_GET_MAX_ZERO NBDKIT_BLOCK_SIZE_GET_MAX_CACHE along with a new callback for plugins: int64_t block_size (void *handle, int which); where 'which' is one of the enum values. A future nbdkit might request an enum value not recognized at the time the plugin was compiled, so the recommended behavior is...

...g future protocol > extensions in whatever we expose to plugins. > > So, I'm thinking something like the following: > > New enum: > NBDKIT_BLOCK_SIZE_GET_MINIMUM > NBDKIT_BLOCK_SIZE_GET_PREFERRED > NBDKIT_BLOCK_SIZE_GET_MAX_DATA > NBDKIT_BLOCK_SIZE_GET_MAX_TRIM > NBDKIT_BLOCK_SIZE_GET_MAX_ZERO > NBDKIT_BLOCK_SIZE_GET_MAX_CACHE enum or int? I think there are ABI problems with enums, although probably not unless we have more than 256 cases? > along with a new callback for plugins: > > int64_t block_size (void *handle, int which); > > where 'which' is one of t...