Re: [PATCH v5 0/5] Initial support for multi-actuator HDDs

[Damien Le Moal <Damien.LeMoal@wdc.com>]

On 2021/08/27 12:03, Martin K. Petersen wrote:
> 
> Damien,
> 
>> I like it, but a bit long-ish. Do you think shortening to access_range
>> would be acceptable ?
> 
> But doesn't 'access_range' imply that there are ranges that you can't
> access? I think 'independent' is more important and 'access' is just a
> clarification.
> 
>> Adding independent does make everything even more obvious, but names become
>> rather long. Not an issue for the sysfs directory I think, but
> 
> I do think it's important that the sysfs directory in particular is the
> full thing. It's a user-visible interface.

Totally agree on that.

> If the internal interfaces have a shorthand I guess that's OK.
> 
>> struct blk_independent_access_range {
>> 	...
>> 	sector_t sector;
>> 	sector_t nr_sectors;
>> }
>>
>> is rather a long struct name.
> 
> True, but presumably you'd do:
> 
> 	struct blk_independent_access_range *iar;
> 
> in a variable declaration and be done with it. So I don't think the type
> is a big deal. Where it becomes unwieldy is:
> 
> 	blk_rq_independent_access_range_frobnicate();

OK. Let me rework the patches with the full blk_independent_access_range type
name to see what everything becomes.

> 
> Anyway. Running out of ideas. autonomous_range? sequestered_range? 

Arg. I prefer independent over autonomous. And "sequestered" is used in the
context of SCSI/ATA command duration limits so I would rather not use that.
I am out of ideas too. Let me try to see with "independent".


-- 
Damien Le Moal
Western Digital Research