[PATCH 10/13] block: introduce BLKREPORTZONESV2 ioctl

[Damien Le Moal]

On 11/1/25 01:52, Bart Van Assche wrote:
>> +	case BLKREPORTZONEV2:
>> +		if (rep.flags & ~BLK_ZONE_REPV2_INPUT_FLAGS)
>> +			return -EINVAL;
> 
> -EINVAL probably should be changed into something that indicates "not
> supported" rather than "invalid argument"?

Not supported could be confused with the cached report zones not being
supported. It is, but the user cannot specify input flags that are not defined.
This is to ensure that undefined flags are always 0 and that we can use these
going forward when we need to define a new flag.
So EINVAL seems appropriate to me.

> 
>> index dab5d9700898..1441d79a6173 100644
>> --- a/include/uapi/linux/blkzoned.h
>> +++ b/include/uapi/linux/blkzoned.h
>> @@ -82,10 +82,20 @@ enum blk_zone_cond {
>>   /**
>>    * enum blk_zone_report_flags - Feature flags of reported zone descriptors.
>>    *
>> - * @BLK_ZONE_REP_CAPACITY: Zone descriptor has capacity field.
>> + * @BLK_ZONE_REP_CAPACITY: Output only. Indicates that zone descriptors in a
>> + *			   zone report have a valid capacity field.
>> + * @BLK_ZONE_REP_CACHED: Input only. Indicates that the zone report should be
>> + *			 generated using cached zone information. In this case,
>> + *			 the implicit open, explicit open and closed zone
>> + *			 conditions are all reported with the
>> + *			 BLK_ZONE_COND_ACTIVE condition.
>>    */
>>   enum blk_zone_report_flags {
>> +	/* Output flags */
>>   	BLK_ZONE_REP_CAPACITY	= (1 << 0),
>> +
>> +	/* Input flags */
>> +	BLK_ZONE_REP_CACHED	= (1 << 31),
>>   };
> 
> Why 1 << 31 instead of 1 << 1?

Why not ? That separates input and output flags instead of mixing them in
tighter definition.



-- 
Damien Le Moal
Western Digital Research