search for: nbdkit_block_size_get_max_data

...en cache could benefit from larger buffer size than pread), which 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...

...size than pread), which > 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 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...