Hi, On Nov,Friday 11 2011, at 1:59 PM, David Holland wrote:
> On Sat, Oct 29, 2011 at 05:14:30PM +0000, David Holland wrote: >> The new discovery that struct ufs_quota_entry is meant to be >> fs-independent changes the complexion of things quite a bit. > > ok, so my poor choice of wording and/or bikeshedding burnout has > caused this thread to run down, except for the terminology part. > > Here's what I'm planning to do: > >> ISTM that there are four more or less separable issues now: >> >> 1. Fix the name of struct ufs_quota_entry and any related things to >> make it clear that they're fs-independent. This is not optional. >> >> 2. Clean up the userlevel quota tools and libquota along the lines >> I previously proposed, giving libquota a clear API and >> centralizing all the legacy userlevel quota code. > > I'm going to proceed on these, since (1) is clearly necessary and > there was not significant opposition to the parts of the previous > proposal that constitute (2). Stating that there was no opposition when current maintainer said that he doesn't think that your change is needed seems to be wrong to me. > > One semi-open question remains: whether the future published/supported > userlevel libquota API should involve #include <quota/quota.h> or > #include <quota.h>. I'm going to go with the latter (no subdir), as > previously proposed, unless someone has a strong opinion and expresses > it fairly soon. > > I am also, as one of the people concerned with the design of the VFS > interface, going to move the xmlrpc processing code out of the > filesystems and institute a relatively simple API for VOP_QUOTACTL. > I'll post what I'm going to do in this regard when I have a design (or > patches) ready. > > Since in the worst case extending the VOP_QUOTACTL interface requires > only a kernel version bump, I think it's pretty clear that this > interface should be kept simple for now. When and if new and > semantically expanded quota functionality should appear in some > filesystem, which is not likely to be anytime soon if ever, we can > adjust VOP_QUOTACTL and swallow a kernel version bump then. > >> 3. Abolish the proplib-based transport encoding. Since it turns out >> that the use of proplib for quotactl(2) is only to encode struct >> ufs_quota_entry for transport across the user/kernel boundary, >> converting it back on the other side, it seems to me that it's >> a completely pointless complication and a poor use of proplib. >> It's also messy, even compared to other proplib usage elsewhere. >> (Regarding claims of easier/better compatibility, see below.) >> >> 4. Abolish the xmlrpc-type user interface of quotactl(8) in favor >> of something else saner and easier to work with. > > I'm going to ask core to decide these two. If the decision is to > proceed on (4) I'm planning to move the xmlrpc processing code into > quotactl(8) and keep it around for a while in case anyone has backup > dumps in that format that they need to convert. ("A while" I think > means a few weeks, not a few releases. If this interface is going to > be removed, I don't think it should be present in netbsd-6.) Why is introducing new form of interface better than using standard \ one even if you do not like it ? > >> - We still need suggstions for better terminology than "quota classes" >> and "quota types". > > This part of the discussion I'm going to try to get started again. > > -- > David A. Holland > dholl...@netbsd.org Regards Adam.