On 11/2/22 5:50 PM, Bart Van Assche wrote:
> On 10/26/22 16:19, Mike Christie wrote:
>> +struct pr_keys {
>> + u32 generation;
>> + u32 num_keys;
>> + u64 keys[];
>> +};
>> +
>> +struct pr_held_reservation {
>> + u64 key;
>> + u32 generation;
>> + enum pr_type type;
>> +};
>> +
>> struct pr_ops {
>> int (*pr_register)(struct block_device *bdev, u64 old_key, u64 new_key,
>> u32 flags);
>> @@ -14,6 +26,18 @@ struct pr_ops {
>> int (*pr_preempt)(struct block_device *bdev, u64 old_key, u64 new_key,
>> enum pr_type type, bool abort);
>> int (*pr_clear)(struct block_device *bdev, u64 key);
>> + /*
>> + * pr_read_keys - Read the registered keys and return them in the
>> + * pr_keys->keys array. The keys array will have been allocated at the
>> + * end of the pr_keys struct and is keys_len bytes. If there are more
>> + * keys than can fit in the array, success will still be returned and
>> + * pr_keys->num_keys will reflect the total number of keys the device
>> + * contains, so the caller can retry with a larger array.
>> + */
>> + int (*pr_read_keys)(struct block_device *bdev,
>> + struct pr_keys *keys_info, u32 keys_len);
>> + int (*pr_read_reservation)(struct block_device *bdev,
>> + struct pr_held_reservation *rsv);
>> };
>
> Is there any pr_read_keys() implementation that won't have to divide @keys_len by 8? How about leaving out that argument and making callers store the number of elements in the keys[] array in the num_keys member before calling pr_read_keys()?
That seems ok to me.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
