On 2021/08/26 12:43, Martin K. Petersen wrote:
>
> Damien,
>
>> I am not super happy with the name either. I used this one as the
>> least worst of possibilities I thought of. seek_range/srange ? ->
>> that is very HDD centric and as we can reuse this for things like
>> dm-linear on top of SSDs, that does not really work. I would prefer
>> something that convey the idea of "parallel command execution", since
>> this is the main point of the interface. prange ? cdm_range ?
>> req_range ?
>
> How about independent_access_range? That doesn't imply head positioning
> and can also be used to describe a fault domain. And it is less
> disk-centric than concurrent_positioning_range.
I like it, but a bit long-ish. Do you think shortening to access_range would be
acceptable ?
we would have:
/sys/block/XYZ/queue/access_ranges/...
and
struct blk_access_range {
...
sector_t sector;
sector_t nr_sectors;
}
struct blk_access_range *arange;
Adding independent does make everything even more obvious, but names become
rather long. Not an issue for the sysfs directory I think, but
struct blk_independent_access_range {
...
sector_t sector;
sector_t nr_sectors;
}
is rather a long struct name. Shortening independent to "ind" could very easily
be confused with "indirection", so that is not an option. And "iaccess" is
obscure...
>
> I concur that those names are a bit unwieldy but at least they are
> somewhat descriptive.
>
> I consulted the thesaurus and didn't really like the other options
> (discrete, disjoint, separate, etc.). I think 'independent' is more
> accurate for this and better than 'concurrent' and 'parallel'.
>
--
Damien Le Moal
Western Digital Research
