On Sat, Oct 29, 2011 at 05:14:30PM +0000, David Holland wrote:
> [...]
> 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.)
Ho no, not again !
The arguments that ufs_quota_entry (or whatever its name is) will
be good enough for any future filesystem is just not true. We already
have been in this argument.
>
> 4. Abolish the xmlrpc-type user interface of quotactl(8) in favor
> of something else saner and easier to work with.
work with with *what* ?
>
> 3. There's already been some discussion of the compat issues in this
> thread. Basically it boils down to: if you send a program material
> that it's not expecting to receive, it won't be able to cope with it
> and will fail/die/crash. This is true whether the material is binary
> or a proplib bundle or text or whatever else.
With a binary it'll probably crash. With a text-based format it will notice
the syntax error return an error code. This is a big difference,
especially for kernel.
>
> 4. If using split on the output of quota/repquota/whatnot isn't good
> enough (in some specific places we may want a machine-readable-output
> option) then the best way to access the quota system from Perl or
> Python (or Ruby or Lua or ...) is with a set of bindings for the new
> proposed libquota. This should be straightforward to set up once the
> new libquota is in place. I think the current quotactl(8) should just
Are you going to provide those bindings ? I'm interested in perl.
> be dropped. Among other things, I've been told that XML-based user
> interfaces are specifically prohibited by act of Core.
I'd like an official word from core on this. I don't remmeber seeing
this stated anywhere.
> - As far as I can tell there is not and never has been support for
> manipulating quotas on unmounted filesystems.
There was in quoya(1), repquota(8) and edquota(8), and I've been using
it with netbsd-5. Just read the code in the netbsd-5 branch to see it.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
