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).
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.)
> - 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
