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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
