On Mon, Nov 14, 2011 at 01:48:17PM +0000, David Holland wrote:
> > > 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.
>
> Neither is good enough if you're providing backwards compatibility;
An error is still better than a crash.
> it
> has to *work*. This is the standard we're committed to, and I continue
> to think there's no particular advantage for proplib in this regard,
> particularly for this particular kind of data.
And I still think a text-based format is better than a binary format for
backward compatibility.
>
> (I don't think any semistructured or "self-describing" data model,
> including the perfect one I'd replace proplib with if I could wave a
> wand to do so, provides any particular advantage for procedure call
> compatibility. Sure, you can tag data bundles with version codes and
> such, but we can and do already do that by tagging the call itself and
> have lots of support architecture in place for doing it that way. The
> advantages appear when you're dealing with irregularly structured
> material, like when there are large numbers of optional fields or
> optional parameters and so forth.)
Or when you send different commands which takes different arguments,
which is the case for the quota syscall and VNOPS.
>
> > > 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.
>
> I don't do Perl. I might be persuaded to do Python bindings, but it
> would probably be more effective to enlist someone who already knows
> how to do this and won't therefore make newbie mistakes with the
> interpreter. Anyway, the hard part is making the library interface
> available; wrapping Perl or Python around it should be entirely
> trivial.
So you propose to remplace something that we can work with using existing
modules it various language, by something that needs a specific module (to
be written) for each langage. Clearly that's not a win.
>
> > > - 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.
>
> I've looked. I don't know what you're seeing, but all I see is code
> for directly manipulating the quota files. There's no logic for
> mounting anything to reach them. So it'll work if the quota files are
> on / and the volume is for /home regardless of whether /home is
> mounted... but only because it doesn't have to touch /home in this
> case.
that's exactly the case I'm in: quotas files in /var/quotas, quotas enabled on
other filesystems and not /var.
> I don't think that feature is worth preserving either, since it's
> purely a side-effect of having visible quota files. And I don't see
> the point; it's not like mounting the volume to run edquota will cause
> a catastrophe.
I dropped this functionnality for ufs-quota2; I used it for ufs-quota1
because otherwise things would go wrong (something to do with offsets:
a uid would get the quotas for another uid - of course this is a bug, but
I never managed to track it down).
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
