On 1/18/16 9:40 AM, Jan Kara wrote:
> On Mon 18-01-16 09:18:16, Eric Sandeen wrote:
>> On 1/18/16 4:33 AM, Jan Kara wrote:
>>> On Fri 15-01-16 11:31:00, Eric Sandeen wrote:
>>
>> ...
>>
>>>> For a purpose-built interface of "find the next ID" that wouldn't require
>>>> any
>>>> structure or interface changes...
>>>>
>>>> We could name it Q_GETNEXTQUOTA / Q_XGETNEXTQUOTA to make it explicit about
>>>> the purpose, and document that return behavior. Done & done. ;)
>>>>
>>>> A new grand unified extensible quota call sounds like a great idea, I just
>>>> hate to gate this work on designing a brand-new interface.
>>>
>>> OK, ok. I like Dave's proposal for quotactl2(). So let's leave the
>>> unification
>>> for later and implent Q_GETNEXTQUOTA and Q_XGETNEXTQUOTA with the
>>> functionality of your original Q_XGETQUOTA2. Having separate call to get
>>> next ID would save us one new quotactl but OTOH we would need two syscalls
>>> (and quota structure lookups) to report one structure and there are
>>> potentially *lots* of them.
>>
>> Ok, I can re-do it with the new Q_[X]GETNEXTQUOTA names, I've already done
>> the non-xfs one as well, just starting testing on that.
>>
>> With or without the flags argument?
>
> Without. For further extensibility I'd really go for the unified API in the
> end.
Thanks. I'll get new patches out in a bit, putting some polish on them and
the userspace, and seeing about a regression test as well.
Realized I need to think semi-carefully about what we do for IDs found on
disk but not in the user database; today I think extN will show everything;
XFS only shows IDs in the DB, unless an ID range is specified - probably
need to keep all behavior the same, without some explicit commandline switches
to do differently.
Thanks,
-Eric
|