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
